Re: L4-Hurd; device drivers

[Marcus Brinkmann]

On Mon, Jan 19, 2004 at 11:28:03AM -0700, Christopher Nelson wrote:
> I have carefully examined wortel, but not knowing what it is supposed to
> do, I could not decide whether or not it was functioning.

Wortel will have two tasks, and I am quite sure it's in the docs (check it
out and complain if it isn't):

* Bootstrap the initial Hurd servers.
* After that is done, provide a wrapper around the privileged L4 system
  calls (to be used by authorized Hurd servers).

> 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.

Well, it's slightly more.  It indeed receives all memory.  Then wortel and
physmem go into an infinite loop waiting for more stuff to happen.  Stuff
that is to be written.  wortel would now create physmem caps for the task
server, and start the task server.  Then it would create physmem and task
caps for the device access server (deva), and start that.  Then the system
can go into a bootstrap that is comparable to the Hurd server bootstrap we
use currently on Mach (ie, the root filesystem can be started).
  
> I guess I don't understand why the physmem server and the task server
> don't need to be running.

Maybe I cutted too much, but of course eventually, and quite early, they
must run.  It goes in this order:

laden
L4
wortel, in parallel with sigma0
physmem
task
deva (device access server), which then starts the device driver framework
root filesystem
* from here on vanilla *
init
auth
proc
...

> 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.

There is provision for the bootstrap case: From one of the GRUB modules a
memory object (container capability) will be created that can be mapped into
deva's address space.  This module is supposed to contain a simple archive
(I posted details about the format to this list a couple of months ago, we
use some weirdo ELF magic, IIRC).  THe archive contains the device driver
framework binaries, plus the initial device drivers.  From there the device
driver framework is loaded and started (more tasks are created), which then
only communicates with deva, which proxies calls to task, physmem and wortel
(thus, the DDF is isolated from the normal Hurd stuff, to make it more
cross-OS applicable).  Deva acts as an intermittent between the Hurd+L4 and
the DDF.  It thus can fake a filesystem early, based on the module archive
content.  Later on, the root filesystem will register with deva to
supplement or override the archive content.

> 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.

Filesystem support is not implemented by drivers, but by filesystem servers. 
The root filesystem must be a GRUB module, started by wortel (after
physmem, task and deva).  The rootserver then can use deva and it is a
requirement that the device drivers for the root fs storage device is in the
deva archive that contains the initial modules (think "initrd").

> 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.

Of course.  This is done via deva, which knows about physmem.

> 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 web page is indeed misleading.  It is also mostly unrelated to the
efforts we are talking about here.  I already said the doc is in
hurd-l4/doc/.  This and the info on this list (at least some of it :) is the
only available documentation right now.  There is no web page that contains
directly relevant info that I know of.

> 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.

As far as I am aware, it does not acknowledge them for you at the CPU/device
level, which is what the paragraph you refer to is concerned about.  I can
not verify what this part of the document says, but if you are concerned
about it, please start a new subject, and maybe include
address@hidden (Peter 'p2' De Schrijver)  and
address@hidden (Daniel Wagner).

> 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.

Deva is really a middle layer that is mostly concerned about wrapping Hurd
stuff into OS independent concepts.  The DDF is quite independent of it. 
Talk to Peter and Daniel about it to get more details.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/