Re: [ANNOUNCE] Gujin graphical bootloader 0.4

[ebiederm@xmission.com (Eric W. Biederman)]

Keith Owens <kaos@ocs.com.au> writes:

> On Mon, 13 Aug 2001 14:05:05 +0200 (CEST), 
> Etienne Lorrain <etienne_lorrain@yahoo.fr> wrote:
> > A good solution would be to have the kernel being two (or three) GZIP
> > files concatenated, the first would be the real-mode code to setup
> > the structure only, the second would be the protected-mode code of the
> > kernel (and the third the initrd). The first part would be a position
> > independant function getting some parameters (address/max size of the
> > structure to fill in) and returning information like microprocessor
> > minimum requirement, video mode supported (number of BPP, or text only),
> > address the kernel has been linked (to load a kernel at 16 Mb), ...
> 
> Before you go too far, there is already an standard for boot loading,
> EFI (Extensible Firmware Interface).  Originally from Intel but it is
> open.  http://developer.intel.com/technology/efi.  IA64 uses this and
> nothing but this, it already loads kernels in ELF format.  There is no
> point in inventing yet another boot interface, unless you cannot do
> what you want in EFI.

Well unless someone removes the architecture specific assumptions of EFI,
and gets it going on every platform there certainly is.  Besides the
fact that despite a complete rewrite the current EFI BIOSes are the
slowest I have seen.  With linuxBIOS I can load a kernel image over
the network before my hard drives spin up to speed.  This isn't always
the right thing to do.  But waiting 45 seconds before you start
booting your operating system is equally insane.

Any bootloader interface that requires a callback for more then a
fatal abort of the loaded image will be misimplemented someday.  Even
on the alpha with it's small selection of Firmware this problem
persists.  So the interface to the firmware needs to be as trivially
simple as possible.

Eric