Matthias Andree wrote:
> As has been laid out, people can use initrds for this.
For obtaining the kernel image, yes, but then they still can't run it.
The "Linux boots Linux" mechanism wouldn't necessarily replace initrd
but rather complement it.
> I am aware of the maintenance issue. This is however a design flaw.
Agreed ;-)
> While I don't expect to circumvent chainloaders for commercial OS's (and
> I don't really care), if there was a carefully chosen sequence that *BSD
> and Linux shared, that would constitute quite a gain.
I'm not that much worried that much about chain loaders and such.
I'm more worried about mechanisms that push the file system to a
higher layer of abstraction, beyond the reach of the boot loader.
Example:
- the Linux floppy boot loader can boot exactly one format, a floppy
with a linear kernel image
- GRUB or SILO can read one or a given number of file systems
- LILO can read any file system that satisfies a set of assumptions
(which are met by a large and still growing number of file systems)
As you've pointed out, with things like SoftRAID, we exceed this
traditional setup. You can of course make GRUB or LILO RAID-aware,
but this is likely to be a) a fair amount of work, b) in constant
need of updates while the RAID code is evolving, and c) under the
constant risk of version drift.
> Yes. Still, you need "old-fashioned" simple boot-loaders,
Exactly. And I want to make their life as easy as possible. There's
enough junk inflicted upon the boot loader from the BIOS. It's nice
if the kernel's changing capability set doesn't add another degree
of freedom - freedom to fail.
My goal is to set an upper bound for how complex boot loaders have
to grow because of kernel features. This still leaves you the
choice of exceeding that bound, if your specific needs warrant the
effort.
> I'd appreciate if the standard bootstrapping sequence was less
> size-sensitive like it is now. LILO is extremely fragile, the kernel
> itself must not exceed a certain size in order to boot. These are
> limitations today.
I have to look into this. So far I'm not sure of the alleged size
limitation of LILO is for real or if it's other things in the system
breaking.
> Since the internal presentation of data varies over kernel versions, you
> will most certainly impose further restrictions on the boot sequence
> such as "2nd stage must be compiled along with the kernel" - exactly the
> opposite of your aim. If you bring data into a generic format, you will
> need additional layers in the kernel -> code bloat. That's ot what you
> want either.
I don't want to pass a lot of information, and it is usually converted
into some more useful form anyway. This should quickly become a rather
stable interface. (Note: some people have been suggesting to launch
new kernels that take over the whole active system, preserving process
contexts, etc. This is not what I'm suggesting. My new kernel won't
know anything of what has happened before, except a few hundred bytes
of hints passed using this stable interface.) In the absence of such
information (e.g. non-SCSI kernel boots SCSI kernel), the normal scan
can take place. Think of it like shown in this piece of metacode with
invented names and structures:
...
for (hint = lookup_boot_hint(BOOT_HINT_SCSI_DEVS,BOOT_HINT_SCSI_MASK);
hint; hint = lookup_boot_hint(hint+1,BOOT_HINT_SCSI_MASK)) {
struct scsi_boot_hint *h = get_boot_hint(hint,NULL);
mark_scan_bus_scanned(h->bus);
/* enter data from hint into SCSI structure */
}
for (scsi_bus = 0; scsi_bus <= MAX_SCSI_BUS; scsi_bus++) {
if (scsi_bus_already_scanned(scsi_bus)) continue;
/* do normal scan */
}
...
No black magic. No ASN.1. No XDR ;-)
- 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 : Sat Jan 15 2000 - 21:00:20 EST