[LinuxBIOS] A very good idea

ron minnich rminnich at gmail.com
Fri May 4 23:27:32 CEST 2007


On 5/4/07, Al Boldi <a1426z at gawab.com> wrote:

> Now, if I read you correctly, you are implying that OFW has overhead that
> isn't needed to just boot another OS.

You did not read me correctly at all. Sorry, I guess I was not clear.
OFW has overhead that it MUST HAVE to boot another OS. That's its job.
LinuxBIOS does not have that overhead; LinuxBIOS counts on the
in-FLASH payload, which it loads from FLASH to memory, and that
payload is what boots another OS.

What I said was, that OFW has this very powerful ability to control
devices, file systems, web servers, GUIs, network protocol stacks,
remote file systems, and so on. That is at once its great strength and
great weakness. It is a strength, since it has so much capability. It
is a weakness because, to function, it has to have all the drivers
written for it that Linux, or Windows, or EFI, has. it can not reuse
exiting drivers from, e.g., Linux. And, sadly, due to short-sighted
decisions by a number of vendors, nobody is going to develop new
drivers for OFW. Any new drivers developed by vendors will be for:
BIOS, Windows, Linux, and EFI, in that order.

Maybe OFW can start using EFI drivers, but at that point, what's the
reason for OFW to exist?

> And LinuxBIOS is a mini BIOS that is
> tagged onto Linux to leverage its driver pool.  Your point is taken.  But
> there is one point you didn't mention:
>
>         OFW is pluggable, which means that it is easily extensible.

That really has no importance or bearing on the discussion that I can
see. I am not sure how it helps. The whole point is that OFW is
already doing a lot, and having it do more is tough, due to the driver
issue.

>
> 1. OFW in itself does not do anything other than provide a framework for
> pluggable firmware.  Knowing how big this empty framework is, defines its
> overhead.  Do you know how big it is?

you'll have to tell me :-)

> 2. OFW provides services via plugins.  These plugins can be anything, even a
> linux kernel, provided it's adapted to conform to the OFW api.  This means
> OFW can easily leverage the linux driver pool without providing any drivers
> itself.

yes, in other words, you can strip all the drivers out of OFW, until
there is nothing left; then, you can add all the capability that
linuxbios has into OFW, so that OFW can run on any hardware; then, you
have OFW do nothing but load a Linux kernel from FLASH.

At that point, you will have done a lot of work so that OFW can do
what LinuxBIOS does now, while removing everything from OFW that makes
it OFW. I am not sure what the point of such an activity would be, but
you can try it.

>
> 3. OFW can easily host a Hypervisor as a plugin as well.

which would be good for?

>
> 4. OFW can also relegate low level BIOS operations to a LinuxBIOS plugin,
> again provided LinuxBIOS is adapted to conform to the OFW api.  But, as the
> OLPC project has shown, they chose to implement this from scratch as it was
> probably much easier that way.  Which makes me think that we can learn
> something from this, and adjust LinuxBIOS to merge with OFW, while still
> allowing LinuxBIOS to act in a standalone manner, using a stripped OFW host,
> for cases where full OFW overhead is too big.

well, give it a try, I guess, and let us know how it works out. I
think you need to start trying to implement some of this stuff, I am
not sure further discussion is all that useful.

thanks

ron




More information about the coreboot mailing list