Re: Getting rid of serverboot

[Roland McGrath]

Thanks for the debugging.  I've checked in similar fixes.
This includes some other changes in gnumach to make boot_info no longer a ptr.

Please test that the current gnumach code in cvs is not broken by that change,
independent of testing the oskit-mach version of kern/bootstrap.c.

Then please test gnumach and/or oskit-mach with the new kern/bootstrap.c
I've checked in on oskit-branch.  That should have all your fixes, though I
did them myself and maybe slightly differently.

Did I gather correctly that, after those small fixes, the new style boot
actually worked for you?  Great!

The absence of MULTIBOOT_CMDLINE is by design.  We could continue to use an
environment variable hack.  But I think it is cleaner to just use a boot
script variable for this.  Note that I made the kernel set
${multiboot-cmdline} so you can use that in a boot script command line.

Incidentally, also note that for oskit-mach, where the oskit has already
parsed all "foo=bar" words in the multiboot kernel command line, I made it
set all such `foo's as boot script variables too.  This seems like the
right thing for the root device, i.e. boot scripts just use ${root} to get
the root=blah from the command line through the general mechanism, and we
don't define ${root-device} any more.  (There's no intrinsic reason why
"root device" should be a meaningful concept to the microkernel.)

In the non-compat case (i.e. boot scripts), I don't do the hacky old option
parsing at all.  So ${boot-args} is not set.  I think we should replace the
diskfs --bootflags argument with an argument for the multiboot command
line.  The only uses of the bootflags within the filesystem
(diskfs_boot_flags) are -i to prompt for the /hurd/init file name, and -d
to pause before starting things.  My inclination is to make both of these
just filesystem command line arguments, so you'd have to edit your boot
script to use those switches (or use a variable substitution to fetch
something from the multiboot command line)--but that now means using the
GRUB command line editor, not rewriting your boot script file on disk.
Then the filesystem itself doesn't need to examine the multiboot command
line's contents directly at all, it just passes it through to init.

If we do that, then I think it makes sense to have the filesystem
just chop the multiboot command line into words and pass them as the
arguments to init, which likewise will pass all its arguments to runsystem.

Off hand, I can't see any reason to worry about keeping backward
compatibility of these things, i.e. --bootflags, the init
--kernel-command-line option, MULTIBOOT_CMDLINE for runsystem.  You'll
update your whole Hurd at once, and you may need to change your boot script.
If you haven't updated runsystem, you'll just be punted to singleuser.
Pipe up if you think I'm overlooking some pitfall that will matter to people.

The only compatibility issue that I'm really worried about is using a new
or old microkernel with a new or old Hurd, and that is not a problem in
either direction because we still have the compat support in
kern/bootstrap.c and we still have serverboot.

Now seems like a good time to disable the default pager features in
serverboot, so we make sure everybody is using /hurd/mach-defpager instead
and gets any swap partition setup out of boot scripts.