Re: Booting

[Marcus Brinkmann]

At Sat, 08 Jan 2005 20:41:57 +0100,
Bas Wijnen <address@hidden> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> Marcus Brinkmann wrote:
> > 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.
> 
> This suggests that a root filesystem cannot run without deva.  I 
> understand that this is true for a root filesystem which needs to access 
> hardware such as a harddisk, but a ramdisk should run fine without deva, 
> so it should be no problem to launch it directly after task.  It should 
> also be the last thing that is started by wortel.  This ramdisk can then 
> start deva and rootfs (it is itself the rootfs for all deva processes, 
> but obviously there should be a different rootfs for the rest).

Well, the idea here would be to already write the root filesystem in
terms of libstore and deva access, and later on just replace the deva
driver with one for a real hard drive.

I don't think that not going through deva would be much simpler, and
it would already be closer to the real thing.
 
> > The root filesystem
> > server would be started by wortel, and is passed as the last module in
> > the grub configuration.
> 
> That's what I propose to change.  The ramdisk should be used instead of 
> deva, as the last module.

You seem to talk about the ramdisk as a task.  This is not how I think
of it.

> deva is started by the ramdisk, not by 
> wortel.  The rootfs is also started by the ramdisk.  And I think it 
> should start the first process as well, there is no reason to let rootfs 
> do that.  So in fact it is a bit more than just a ramdisk, it also 
> starts some tasks, although technically that part could still be done by 
> wortel.  The only essential part of it is the driver archive, because it 
> is used as the root filesystem for deva.
> One good thing about not using wortel is that the bootstrap code doesn't 
> stay in memory when booting has completed.  In fact, it might also be 
> possible to use it for starting task (but physmem is more tricky, I 
> guess, as it cannot give wortel's memory to it).

Maybe I still don't quite get it, but I don't really see any
advantage.  The bootstrap code is not much, and we could construct
wortel in a way to allow it to be dropped (but I would want to keep it
- if wortel becomes a real manager OS, you could do "soft reboots").
 
> > Maybe we mean different things with ramdisk.
> 
> What I mean with a ramdisk is a process which can be used as a root 
> filesystem for an other process, and which does not need hardware 
> drivers.  While I am thinking of this as a traditional ramdisk, it can 
> be anything as long as it doesn't need deva to run.  :-)

A traditional ramdisk is not a process.

I still don't understand if you are proposing this as a temporary
thing or as the "real thing".

> I don't see what this has to do with what I wrote, you probably didn't 
> understand what I was saying (which I guess is my fault).  I was just 
> addressing a minor (and currently quite unimportant) problem, assuming 
> that we want to free memory used for booting when booting has completed.

Ok.  So if this is what you want to address, then you should have said
so clearly, because this can be addressed in different ways, too.  In
particular, wortel could be changed to drop the booting code.

I am not sure if you achieve your goal in your design - to establish
this, we would need to go in much more detail of your proposal.  But I
am sceptical.  You are also mixing two topics: The design of a ramdisk
(running the root fs without real hard drive from memory) and the
bootstrap code issue, and this is confusing at best, and misleading at
worst.  I don't think they are related at all.
 
> After thinking a bit more about it, I meant "processes which use libc" 
> when I wrote "normal processes".  Since libc will need physmem and task 
> (for malloc and fork, for example), those cannot use it.  It also needs 
> a root filesystem, I suppose, although perhaps it could even work 
> without one (although that would make using libc as a shared library 
> impossible, and is therefore highly undesirable).

You are quite wrong.  ext2fs.static on the Hurd on Mach uses glibc,
and there is not much special magic at all, and it is in fact just the
very same glibc as used by others.  Of course you can not link ext2fs
dynamically.
 
> The reason I was thinking of this alternative bootup method is that I 
> would prefer to use libc for as many processes as possible, because not 
> using it makes it harder to write them.  However, there are other things 
> to think of, such as using the hard disk as soon as possible (so we 
> don't need strange things like prepared ramdisks a lot, or even at all).

I don't see any difference in glibc usage in your proposal from what
we already want to do.

> > Then I can get back to glibc, and see that I can get the startup for
> > statically linked programs working.
> 
> You mean fork(), or execve()?  Or a combination?
> Is the protocol (especially with the communications with task) already 
> determined?

No, I mean internal glibc startup code (initialization etc).
 
> I was thinking of writing the ramdisk thing I described above.  I only 
> need to know the interface which it has to provide.  Is it already clear 
> how tasks will communicate with their filesystem?  I guess this is in 
> libc.  Is the implementation currently used on mach usable on L4, or is 
> it mach-specific?

Some things will be the same, others different, as usual.  See the pdf
for some more information.

Thanks,
Marcus