One example is VGA. It's not a bus. But if you are saying it is not the BIOS' task to enable VGA. Whose is it.
The kernel (or some userland, preferably/partially) needs to be able to initialise graphics controllers from the ground up, to support sleep modes (and also to support more-than-one-card setups, in the legacy BIOS case). This is a well-understood problem in the Linux graphics world, but quite hard to solve it seems -- it is taking forever. Some progress is being made though.
If LB wants to use the graphics hardware by itself, i.e. for the boot menu or something similar, it of course has to init the graphics and contain a minimal driver, too.
Calling a VGA option rom in a bootloader is about as wrong in my opinion as initializing DRAM in an OS kernel is.
It is philosophically wrong, and hard to make it work reliably too, esp. in a generic cross-vendor way. It is more of a band-aid than an actual solution.
Devices are never _driven_ by LinuxBIOS after the payload has been started however,
It can be useful to have a single callback into LB to display debug output on whatever the debug output device is. Anything more than that is quite not in line with the LB philosophy I'd say; you'd be better of using a full blown Open Firmware implementation if you want a feature-rich boot environment.
However - LinuxBIOS will need to "hand over" the system to the payload and I guess that the formalization of this handover is what this thread is all about.
honestly, I dont think so. The handover is loading an ELF file. How unformalized can that be.
The handover is the jumping to the ELF entry point, instead ;-)
Segher