Re: Getting rid of serverboot

[Neal H Walfield]

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

Checked.  It works fine.

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

I checked it with GNU/Mach; it works fine.

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

Affirmative.

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

I agree.  Here is a small patch to fix an error:

2001-08-20  Neal H Walfield  <neal@cs.uml.edu>

        * kern/bootstrap.c (bootstrap_create): Set multiboot-cmdline,
        not kernel-command-line.
        Fix indentation and comments.


Index: bootstrap.c
===================================================================
RCS file: /cvs/gnumach/kern/bootstrap.c,v
retrieving revision 1.3.2.8
diff -u -p -r1.3.2.8 bootstrap.c
--- bootstrap.c 2001/08/20 10:49:47     1.3.2.8
+++ bootstrap.c 2001/08/20 12:52:55
@@ -129,18 +129,18 @@ void bootstrap_create()
        panic ("cannot set boot-script variable device-port: %s",
               boot_script_error_string (losers));
 
-       losers = boot_script_set_variable ("kernel-command-line", VAL_STR,
-                                          (int) kernel_cmdline);
-       if (losers)
-         panic ("cannot set boot-script variable %s: %s",
-                "multiboot-cmdline", boot_script_error_string (losers));
+      losers = boot_script_set_variable ("multiboot-cmdline", VAL_STR,
+                                        (int) kernel_cmdline);
+      if (losers)
+       panic ("cannot set boot-script variable %s: %s",
+              "multiboot-cmdline", boot_script_error_string (losers));
 
 #if OSKIT_MACH
       {
        /* The oskit's "environ" array contains all the words from
           the multiboot command line that looked like VAR=VAL.
           We set each of these as boot-script variables, which
-          can be used for things like ${root-device}.  */
+          can be used for things like ${root}.  */
 
        extern char **environ;
        char **ep;

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

This is not true in the GNU Mach case (boot_strap_create still calls
get_compat_strings in the multi-module case).  I think that it would not
be to had to write a small routine to break up kernel_command_line into
boot script variables.  Give me the word and I will write up a small
patch.

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

I agree.

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

Nope, I think that this is a good approach.

pgpQ604maKzlm.pgp
Description: PGP signature