Re: Booting

[Marcus Brinkmann]

At Fri, 31 Dec 2004 00:43:13 +0100,
Bas Wijnen <address@hidden> wrote:
> Currently my system boots until task.  I still haven't tried Marcus' 
> deva things.  Anyway, I was wondering what more is needed to boot the 
> system.
> 
> I would expect that after task, a ramdisk can be used as rootfs, from 
> which deva can be started.

The idea is that the module after deva is the deva initial driver
archive, which is a bit like linux's initrd.  It would contain all
drivers needed before the root filesystem is up.

I always planned to use a fake driver in there which would take its
filesystem data from the initial driver archive itself.  OTOH, a
simple IDE driver doesn't seem to complicated after all, so that is
also a possibility.

> I know the idea is to use a working deva for 
> starting rootfs, but that would put limits on the deva boot (with a root 
> fs, it can consist of normal processes, as they have everything they 
> need: physmem, task, and rootfs).  Since a ramdisk wouldn't need any 
> device drivers, I don't see a problem with it.

I don't understand the beginning of the sentence.  The root filesystem
server would be started by wortel, and is passed as the last module in
the grub configuration.  The driver archive for deva should only
contain deva drivers, which are hurd-independent.  The root filesystem
is a hurdish server task and thus outside of the deva archive.  But it
was my plan to make it use a deva ramdisk driver.

Maybe we mean different things with ramdisk.

> Well, I see one problem: the ramdisk is only used for bootstrapping, and 
> should be disposed of when the system is running.  So it would be useful 
> to have a "change root fs" method at least for deva and the first device 
> drivers (particularly harddisk and the "real" rootfs).

The module after deva is the deva driver archive, which contains
initial drivers that may be needed to get at the real root filesystem
(ie, /dev/hda5 or whatever).  The filesystem server would be
configured to access a store (-T device:hda5 for example, or -T
part:5:device:hda) and communicate with deva to get at the raw storage
data.

My idea was to initially have a deva driver which uses a file in the
driver archive as storage data, which would be loaded into memory.
But an IDE driver is also possible.

 
> Am I right that "normal" processes can be started when the root fs is 
> ready?  Can libc already be compiled?  (I expect every normal process to 
> need it.)

The root filesystem server itself will be started by wortel just as
deva is, but with even more bootstrap information (the device master
port, for example).  This is a straightforward addition, and Neal
already has patches for that I believe.

Then the rootfs will be responsible for the actual hurd bootstrap,
just as we have it today: Loading and running init, auth, proc, etc.
These are normal processes, yes, but there is still some bootstrap
magic, as for _really_ normal processes you would expect auth, proc
etc to already run.  But the amount of magic is relatively small and
we already know what it is, as it is the same in the current Hurd on
Mach.

I have a hacked copy of glibc which compiles on a hurd-l4 target, but
it is not yet operational.  It compiles, but it certainly doesn't run.
The reason is that I started off with nptl and tls support, so at the
very beginning glibc starts to initialize the tls stuff, which
requires sbrk to work.  So we are immediately hitting memory
allocation issues.  However, we are making progress on that - Neal
worked on physmem recently, and a patch is under preparation which I
am going to review soon (I don't have it yet :).

Then I can get back to glibc, and see that I can get the startup for
statically linked programs working.  It's a pain in the ass, of
course, and for a real functional library there is a lot of work to be
done.  But I hope that with some simple stubs I can get it so much as
to call main() and allow incremental process.  This shouldn't be too
far away, although it won't be the real thing.

So, if you wanna help, there is a lot you can do, but you should wait
just a few more days for Neal's work to get in, which should be by the
weekend.  And then I will commit whatever glibc stuff I have which is
not much, but offers endless opportunities to hack. :)

Of course, you could also work on deva related stuff so we actually
have some storage to run off.  That could be done right now
independently of what we are doing - a simple implementation would use
string items for reading/writing or so, and not containers.

Thanks,
Marcus