[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christopher Nelson
Subject: RE: L4-Hurd; wortel's missing modules; was: (autoreconf errors)
Date: Fri, 16 Jan 2004 15:56:40 -0700

>"Christopher Nelson" <address@hidden> wrote:
>: I have looked at all that, but I didn't know how much was 
>actually done.
>: (If anything.)  The physmem server seems to be in place already.
>The physmem server is far from done.  I've done a bit of work 
>on it (nothing public available yet, though) but I stopped 
>since the API has not been specified to full extent, yet 
>(Neal, where are you?) Marcus also has to finish libhurd-cap 
>before any fun stuff can work.
>When it comes to the other core services, there has only been 
>done work on wortel (the root server.)  Niels has said that he 
>wants to write the task server (but I'm not sure that is 
>correct any longer.)

Ah hah.  So physmem exists, but isn't complete.  I saw the module and
assumed that it was functional.

>: Nothing very interesting can happen until we have device 
>drivers, b/c we
>: can't even talk to the disks to load interesting programs until that
>: happens.  I am assuming we want to have user-space drivers, 
>and that the
>: primary drivers (e.g. persistent storage and filesystem) 
>will be loaded
>: by GRUB.  From then we can have some program in charge of looking at
>: what hardware is in the machine and loading the correct drivers.  
>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.

>: I have seen that there is interest in enabling the Linux DDE in the
>: context of Hurd.  Is this primarily so that Linux drivers can be used
>: straight-up from Hurd, and so that Hurd does not need to 
>maintain it's
>: own drivers?  
>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).

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?  

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

The same problems are confronted in any sort of OS.  For example, when
you enable the memory paging device, the pages must be setup to
translate where you are to where you were, otherwise the processor
starts pulling bogus info.  So, of course, what everyone does is to
identity map the initialization area into the page tables.  Equally so,
you cannot start any tasks until you have a TSS setup.  So you simply
build a TSS around where you are, or where you want to be, and then
"switch" to that task.

Just some thoughts.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]