rEFIt

That sounds like it's not possible, closing as invalid. Thanks for all the
explanation!

The BIOS emulation in the firmware does it all on its own. It actually
needs to throw most of the EFI environment out, and switch the processor
from protected mode to real mode before it can start the BIOS boot process.
The "interface" rEFIt uses to engage the process is a special EFI
application that takes care of all the details, and the only parameter you
can give it is one of the strings "HD", "CD", or "USB".

Thanks for your detailed answer.

Yes, as a scientist I agree that this is a solved problem since I can
reduce booting Linux to loading grub. But on the other hand, just the grub
bootstrap itself for some reason takes a substantial amount of time. Of
course, I hope that suspend will be fixed soon on Linux and I don't need to
boot all the time :)

As far as elilo is concerned, I'm not sure it's really the way to go,
though if it would manage to boot Linux with console graphics I guess it'd
be sufficient.

I must admit that I don't know anything about how the BIOS emulation
works, so your explanation is greatly appreciated. Does the BIOS emulation
load the boot sector itself, or does it require it preloaded somewhere?

Well, there are two reasons.

One, there's no point spending time to write another Linux kernel loader
when there are several working ones already, and there are no new features
you could add by reimplementing.

Two, to boot with BIOS compatibility enabled, which is (AFAIK) still
required to get useful graphics output, you need to give control back to
the firmware, which turns itself inside out and switches the CPU to Real
Mode, then runs through a standard PC boot sequence. So rEFIt and the code
that loads the Linux kernel run at different times in very different
runtime environments, so they have to be separate.

As far as elilo specifically is concerned, there are certainly
improvements that could be made to let rEFIt and elilo work together really
smoothly. Even then, merging them would not necessarily be an advantage --
there are many situations where people might want to use elilo, but not
rEFIt. Shipping elilo as part of the rEFIt disk image would be an option,
but first elilo would need to become more useful in the first place, i.e.
able to boot Linux on a Mac with working console graphics. :)