L4-Hurd; device drivers

[Christopher Nelson]

>The code in the hurd-l4 archive is mostly concerned about 
>parsing ELF images, shuffling memory around and keeping track 
>of what happens.
>
>The very first thing you should do is to read the source code 
>carefully.
>Then you would already know all that ;)

I have carefully examined wortel, but not knowing what it is supposed to
do, I could not decide whether or not it was functioning.  I do know
that it is not getting out of server_bootstrap_requests() since I
inserted output comments to help me see where it's going.  It receives a
number of messages and then stops.  Of course the while(1); at the end
of the function was an interesting hint that it doesn't seem to do much
of anything too.

Given the code in wortel it sure looked like the physmem server worked,
since it seems to have a protocol for letting physmem get at all the
memory.  And physmem itself has Doug Leah's malloc in it, so w/o looking
terribly carefully, seemed like a lot more than a dummy module.
 
>> Sounds like a plan then.  I will look at what needs to be done to 
>> implement that.  Obviously the task-creation and physical memory 
>> servers need to run b4 the device drivers can run.  Since L4 already 
>> does all of the thread control, isn't the task server mostly 
>> interested in book-keeping?  And is it that the book-keeping 
>depends on libhurd-cap?
>
>You claim to have read the design docs, but either you 
>haven't, or you didn't understand them (which wouldn't be a 
>tragedy, it's not at all easy, and they are not written to be 
>easy understandable either!).  So please refer back to them 
>and ask questions about them if you don't see why that is 
>explained there.

I guess I don't understand why the physmem server and the task server
don't need to be running.  The design doc cleary states that bus drivers
may even need to load modules from disk to support themselves, which
sounds to me like most of the initial system needs to be up before
device drivers can run.  In fact, there are even driver dependencies:
e.g. persistent storage drivers and filesystem drivers for the boot
device must be up b4 other drivers so that loadable driver modules can
be loaded.  All of that requires the ability to allocate memory and for
some hardware server to be running so that dependency issues can be
resolved.  Also, the physmem server must be queried for zero-copy
operations so that the mappings can be manipulated properly.

It seems to me that the information on the webpage for L4/Hurd is
misleading, since it points to a strong desire to use the Linux DDE
stuff.  Probably that should be removed.

The information about low-level hardware in a PC system is somewhat
dated.  It is no longer the case that a PC has two 8259 interrupt
controllers, and has not been the case for some time.  Instead, there is
an integrated I/O controller that can APPEAR to behave like to 8259's.
In any case, why do we care about that?  L4 handles all that sort of
stuff and reflects interrupts back to user space.

I would be happy to write the deva (including omega_0) from the
specifications in the docs directory, if that is the latest.  If there
is later information somewhere, then I would be happy to read through
that too.

        -={C}=-