"H. Peter Anvin" <hpa@zytor.com> writes:
> Eric W. Biederman wrote:
>
> > I am reluctant to go with a bootimg like interface because having a
> > standard format encourages people to standardize. Though a good
> > argument can persuade me. I don't loose any flexibility in comparison
> > to bootimg because composing files on the fly is not significantly
> > harder than composing a bootable image in ram. Please tell me if I haven't
> > clearly answered your concerns about
> > being locked into a single image.
> >
>
>
> I have to think about it. I'm not convinced that this particular flavour of
> standardization is a step in the right direction -- in fact, it is *guaranteed*
> to provide significant additional complexity for bootloaders, and bzImage
> support is still going to have to be provided for the forseeable
> future.
It is not my intention to deprecate bzImage at this time. But instead
to provide an alternative.
> Since
> you express that it will basically be necessary to stitch the ELF file together
> on the fly I don't see much point, quite frankly; it seems like extra complexity
> for no good reason.
This part is only for people using the kernel as a bootloader. My
apologies if I didn't make it clear.
Let me clarify a little with usage. I have three cases I am targeting.
1) LinuxBIOS.
I need a kernel format that doesn't unconditionally do 16bit BIOS
queries, as there is no 16bit code in LinuxBIOS. bzImage doesn't
work.
2) Portability.
For this I have with some simple bootstrap program that loads the
kernel. And then I have the kernel driving devices and acting a
super bootloader. Something like Grub but with the full power
linux can bring to bear on the issue. This is all I need to
standardize the user booting experience on multiple platforms.
3) Network Booting.
There is not much chance to change bootroms once they are flashed
so they like LinuxBIOS need a general purpose interface, so that can
handle whatever they need to boot.
On the dynamic stitching/initramfs side, the code should really be no
more complex than the current bzImage loading with ramdisks. And if
bootloaders want to keep it simple can drop any optional ELF features,
which should be much simpler than todays bzImage.
Now I will shut up and let you digest this.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:31 EST