No subject

used. For e.g. if my code knows it can't drop back to real mode and
use legacy BIOS interrupts, then it can skip it or use an alternative
(in this specific case, I only used legacy BIOS interrupts to allow
the user to select and change the video mode).

> > Consider the multi-boot specification. OS developers can write code
> > that complies with the multi-boot specification without regard to any
> > bootloader, and bootloader writers can write code with that complies
> > with the multi-boot specification without caring about any OS. Despite
> > this, all OSs and all boot loaders that comply with the multi-boot
> > specification will work together without problems. The same applies to
> > EFI and OpenFirmware.
>
> I think some of this is actually more in the domain of EFI and Open
> Firmware than in LinuxBIOS, which is more a low level firmware. So we
> should work on getting EFI / OFW easily usable as an interface for everyone
> instead of defining a third interface. to the OS and user. Our interface
> is to OFW / EFI though (plus other options of course)

Put more generally, all interfaces between components developed by
different parties should be adequately documented. This includes the
interface between hardware and LinuxBIOS, the interface between
LinuxBIOS and it's payloads, the interface/s between payloads and
anything that use the payload/s, the interface between boot loaders
and OSs, the interface between an OS and software designed for that
OS, etc.

BTW I'm more interested in "boot from ROM" systems, where the "OS" is
stored in ROM, and doesn't require or rely on disk drives or
networking (but may use disk drives and/or networking if present,
after the system is running). GRUB, Openfirmware and EFI payloads
would consume too much of the limited space in ROM.


Cheers,

Brendan