[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Getting rid of serverboot
From: |
Neal H Walfield |
Subject: |
Re: Getting rid of serverboot |
Date: |
Mon, 20 Aug 2001 17:16:08 +0200 |
User-agent: |
Mutt/1.3.18i |
> 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
- Re: Getting rid of serverboot, (continued)
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/16
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/17
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/17
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/18
- Re: Getting rid of serverboot, Jeroen Dekkers, 2001/08/18
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/18
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/18
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/19
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/20
- Re: Getting rid of serverboot,
Neal H Walfield <=
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/21
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/23
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/23
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/24
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/24
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/24
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/24
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/24
- Re: Getting rid of serverboot, Neal H Walfield, 2001/08/24
- Re: Getting rid of serverboot, Roland McGrath, 2001/08/24