Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allowdriver - Plan9

This is a discussion on Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allowdriver - Plan9 ; On 12/6/06, Lucio De Re wrote: > > I guess the Plan9 Kernel could be separated in two layers, the upper > > one just doing "high-level" and 9P-protocol stuff, and a lower one, > > providing the #-channel interfaces ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allowdriver

  1. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allowdriver

    On 12/6/06, Lucio De Re wrote:
    > > I guess the Plan9 Kernel could be separated in two layers, the upper
    > > one just doing "high-level" and 9P-protocol stuff, and a lower one,
    > > providing the #-channel interfaces to the upper layer and doing I/O.

    >
    > My thoughts are along similar lines. My approach would be to expose
    > the device drivers in a hardware dependent "BIOS" as Plan 9 devices,
    > adding only as much OS glue at this level as makes this possible.
    > This would be as close as damn what we know as 9load today.
    >
    > The Plan 9 kernel is the only one that would be able to interface to
    > this BIOS currently, but over time it ought to be possible, mutatis
    > mutandis, to boot other OSes on this layer. My dream is that the BIOS
    > could then be extended by the hordes of device driver writers and
    > every compliant OS would be able to use new devices immediately.


    well, we're trying to sort of do that now. We're using linux as the
    driver layer. It's not what you guys want implementation-wise, but it
    is something like the idea.

    It's not that drivers are fundamentally hard. It's that the hardware
    we work with is undocumented crap. Linux drivers know all the secrets;
    we're riding on that knowledge.

    ron

  2. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    yep. right on the money.

    Theo, who's been a champion for more open hardware documentation, has a
    really nice set of slides on this topic:




  3. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    I am keen enough to try and get some hardware documentation, and maybe
    even have a go at codeing a/some drivers for plan9.

    I only use hardware which plan9 is compatible with so I don't know
    which way to look. At IWP9 modern, inexpensive SATA cards where
    mentioned as somwhere we had a gap in our coverage.

    Is this all we need? Can anyone suggest a card that fits the bill?

    how about modern laptops, we have a ⅞ finished centrino driver which
    needs to be finished off, but what graphics chipset is common enough
    to make it worthwhile chasing the manufacturer, is nvidia still king?
    Do they have weird interrupt controllers, southbridges etc which will
    cause problems?

    As usual I promise nothing but I will do what I can.

    -Steve

  4. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow


    "Steve Simon" writes

    |
    | I am keen enough to try and get some hardware documentation, and maybe
    | even have a go at codeing a/some drivers for plan9.
    |
    | I only use hardware which plan9 is compatible with so I don't know
    | which way to look. At IWP9 modern, inexpensive SATA cards where
    | mentioned as somwhere we had a gap in our coverage.

    plan 9 does support the marvell chipset. for example:
    http://www.supermicro.com/products/a...C-SAT2-MV8.cfm
    this is an inexpensive card.

    as for on-board sata, plan 9 does support the sata on nforce430
    (and maybe most nforce) boards, but doesn't seem to support
    many modes of ich[5-] sata+pata hackery. i think fixing that
    would yield the most bang-for-the-buck.

    personally, these things are also at the top of my list
    - usb ohic and ehic.
    - gbit ethernet: forcedeth, tg3.

    - erik

  5. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    The SATA controllers I've encountered so far either emulate ordinary
    (P)ATA controllers or have a BIOS setting to optionally do so. I'm
    not sure that there's much to be gained by implementing the AHCI or
    other oddball interfaces.

    As I mentioned at IWP9, I'm integrating Charles Forsyth's OHCI driver
    into the devusb framework, and will probably end up having to write
    EHCI (USB 2) support. I've been working on getting Richard Miller's
    usbsfs working with a dozen or so USB disk-like devices (MP3 players,
    DVD drives, flash disks) and they are now mostly working, after adding
    code to probe and use LUNs (logical unit numbers). Some of the dumber
    devices seem to be very sensitive to exactly how you talk to them and
    go off into the weeds if they don't approve, so getting a version of
    usbsfs that they can all talk to is taking longer than expected.

    Gigabit Ethernet seems to be pretty well handled; we've got drivers
    for the Intel controllers (though Intel keeps introducing new
    not-quite compatible variations) and the Realtek 8169, though it
    pauses and thus has low throughput on my machine. Do the other
    gigabit controllers appear on lots of motherboards?


  6. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    > Do the other gigabit controllers appear on lots of motherboards?

    broadcom (tg3) used to be _the_ ethernet for opterons for quite some
    time (we saw one board by iWill which had intels only this year for
    the first time)...

    all our opterons have an 8169 stuck in a pci slot...

  7. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    >>how about modern laptops, we have a ⅞ finished centrino driver which
    >>needs to be finished off, but what graphics chipset is common enough


    since i've got a modern laptop, i'm hoping to do an i3945 802.11abg (ok, bg) driver
    over christmas, in front of the fire, in between mulled wine and hot toddies.
    hmm... wireless and legless. it's not tuneless, because i've got a good set of CDs.

    the incomplete linux driver with binary blobs is only just over 16,000 lines, so how
    hard can it be? hmm. the free/open bsd driver is only 2800 lines.
    shome mishtake shurely.

  8. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    On 12/9/06, Steve Simon wrote:
    > I am keen enough to try and get some hardware documentation, and maybe
    > even have a go at codeing a/some drivers for plan9.


    This is great. All these hardware driver ideas are fine.

    But lacking a few other bits, i still believe that all the drivers in
    the world are not going to be sufficient. I don't even thinks they are
    necessary to get people going.

    Put it this way. I have a nice web page served out of a Plan 9 system
    that shows google maps data etc. I can't view it on Plan 9. What we
    have here, is failure to communicate. Drivers won't help this problem.

    So what we're trying to do is give people a path from the linux world
    to a better place. The idea is that you'll get a linux kernel as a
    device driver. You can even do driver development on Plan 9 in this
    world if all works out. The linux kernel will simply ignore the
    existence of a piece of hardware; Plan 9 will own it. Over time, more
    and more bits can be moved to the Plan 9 domain, until at some point,
    we realize that on that particular system, we don't need Linux at all
    -- and it vanishes in a puff of smoke and mirrors.

    This will be way less extensive than xen-knoppix, which is a full
    distro more or less. We don't need X11 -- Aki has got drawterm working
    on /dev/fb. Systems get pretty peppy once x11 is out of the picture.
    We've realized that we need python to run xen, so one thing we might
    do is remove all of gnubin and just have a few .py utililties, so as
    to minimize the amount of junk we need to have on the linux dom0
    partition. If you have python (NOT that I want it; but you can't avoid
    Python and XML RPC in Xen, sigh), and you can import os, it's hard to
    see why you want all the gnubin junk. How many implementations of cat
    do you need, really?

    For apps, you can run a linux app in a window under VNC. Aki has
    plumbing working between the two worlds. So our browser for now is the
    "light" firefox with its slim-waisted 200 MBYTE footprint.

    Think of this stuff as analogous to the V5 JCL command, or the GECOS
    field in /etc/passwd; a way to get by until you can cut the cords to
    the old-style, primitive environment. And you only use that
    environment in a batch mode ...

    So, for those of you who don't wish to write drivers, there's still a
    large number of us who would appreciate a web browser ... and abiword
    or similar or ....

    thanks

    ron
    p.s. Aki leaves in a week, and we're all very sad here. He was on a
    training assigment, and unfortunately did not train us as much as we
    had hoped. But, hope springs ever anew ... any students wishing to
    spend some time here training us are most welcome to! Note that it's
    easier for me to set up if you are a .us, but hey, Aki is from Finland
    and we still managed it, even though he doesn't speak Linux.

  9. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    16k lines ????
    Really?

    On 12/10/06, Charles Forsyth wrote:
    > the incomplete linux driver with binary blobs is only just over 16,000 lines, so how
    > hard can it be? hmm. the free/open bsd driver is only 2800 lines.
    > shome mishtake shurely.
    >
    >


  10. Re: Again: (self)hosted Plan9? Was: [9fans] extending xen to allow

    h% wc -l *.c
    16731 ipw3945.c

    and don't forget the binary user-mode supervisory program

+ Reply to Thread