Re: L4-Hurd; wortel's missing modules; was: (autoreconf errors)

[Marcus Brinkmann]

On Fri, Jan 16, 2004 at 03:56:40PM -0700, Christopher Nelson wrote:
> Ah hah.  So physmem exists, but isn't complete.  I saw the module and
> assumed that it was functional.

The purpose of physmem in the source is to show how another module is built
and loaded by laden/wortel, to get an idea how the bootstrap will work.
Thus the physmem stuff in the source is a skeleton for a module initially
loaded by the bootloader and then started by wortel.

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 ;)
 
> >True, the initial drivers will most probably be loaded with GRUB.
> >How that will be done is not yet determined, though.  There 
> >has been talked to put them in an archive, or load them 
> >one-by-one as a module.
> 
> It appears that Mach/Hurd used the archive approach and then abandoned
> that in favor of a one-bye-one approach.  I don't know why that was
> done, but it seems to me that if they switched from one to the other
> then that experience should tell us which way to go.

GNU Mach never had user space device drivers.

We already know how we will handle this.  You create an archive with device
drivers you need at boot time, similar to initrd.  This is then
_transparently_ available to the device driver framework before the root
filesystem is up and running.  Later on it will be overwritten/extended by
the real filesystem.
 
> >Yes.  Writing and debugging drivers is a huge job, so if it is 
> >possible to re-use any drivers from Linux, that would be a 
> >good thing (tm).
> >This already done for GNU Mach, and pfinet (the network stack 
> >is from Linux).

However, we figure that it is impossible to use Linux drivers and maintain
our ambitious performance goals (like user-space zero copy).  Plus, because
the Linux DD framework is not stable, maintaining such glue code is a
nightmare.  This is why we decided to have our own drivers.
 
> 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.

> >: As far as how to setup the initial tasks, why has there not been
> >: agreement? Is it political, or is it that no one really has 
> >a good idea?
> >
> >Marcus has an idea that when a service comes up, it reports 
> >back to wortel (which is the root task in hurd-l4), which 
> >propagates the provided information to the other bootstrap services.
> >
> >What I was talking about is what information wortel should 
> >provide to the bootstrap servers, so that they can get on 
> >their feet.  It is not trivial task to boostrap a multiserver 
> >operating system.  For example, physmem can not create any 
> >threads before the task server has been started, and the task 
> >server can not operate without physmem (since it is in control 
> >of all physical memory.)
> 
> That's not quite true, since memory has already been set aside for the
> images of the programs that are running, for the kernel, the modules,
> etc.  Obviously someone has to start or nothing will ever get done.  Why
> can't the task server simply set aside enough memory to start up
> physmem, then start physmem and tell physmem what regions of memory have
> already been used?  I know that that is such an obvious solution that it
> has already been thought of, so I'm curious what the problems are.

Because exceptions should be kept to a minimum.  In your model, the task
server needs to know how to manage memory and start physmem.  That is
unnecessary, and just dead code in the wrong place.  Instead, physmem can be
run before the task server, and the task server can use physmem to get
memory like any other task in the system.  The bootstrap problem is easily
solved by providing physmem with some initial threads to begin with (wortel
can do that easily).  This way the complexities of bootstrap are hidden as
much as possible in wortel.

I am not sure if Johan forgot all this or if I never told him, but I think I
already figured out most of these details when we last worked ont his stuff.
The problem for me is to get time to finish libhurd-cap, which is of utmost
importance and, sadly, quite a challenge.  However, I am quite determined to
do it in February.

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/