Ronald G. Minnich wrote:
> Why does LOBOS do it in the kernel? well, there are cases you want to let
> linux boot linux without even getting to running a user-mode process.
> Think of linuxbios ...
>
> Now that I've said this I'll see Werner's v3 tomorrow that does this too
> :=)
No, v3 doesn't have this ;-) It would be reasonably simple to add a
function that loads the file in the kernel and then calls boot_image,
but I'm not sure this is really all that useful.
Consider what you have to do in the general case before booting:
- pick a kernel
- maybe pick an initrd
- maybe obtain a command line, possibly derived from the original
command line
- maybe massage/reconstruct some of the boot parameters
While you could do most of this in the kernel, you'll end up with a fair
amount of policy in there, plus a huge command line. That's why I prefer
to leave this to user space.
Going via user space adds the following overhead in the simplest case
(i.e. doing what you'd do in the kernel):
- you need the RAM disk driver
- you need initrd
- you need a tiny initrd with a staticly linked binary that grabs
the command line (e.g. from the environment, so you don't need
/proc *) and calls sys_bootimg
(* you probably also want to add escaping of blanks to init/main.c
in this case, e.g. ... next_cmd=root=123\ foo=bar ... (or use
double quotes or do something Tcl-ish and allow for nested strings,
etc.) This would also be needed in the kernel-only case.)
The advantage here is that any extension (e.g. in your case, a boot
prompt might be useful, so you don't have to do it in the boot loader)
can be easily done in user space and you don't need to add policy to
the kernel. Also, once you have the required base functionality, it's
easy to extend it, e.g. you could add limited shell capabilities, or
use something like busybox (http://busybox.lineo.com/).
The disadvantage is of course that packaging gets a little more complex
and that your loader grows a bit (by the rd and initrd drivers, plus
the initrd itself). Is this a problem ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:09 EST