No subject

wanting to implement some form of code reuse.  And to reuse code
things must share and cooperate.

I will argue that if want code reuse someone should be a library of
the functions that will be reused.  Then we don't need multiple
PAYLOADs and all of the associated nastiness.  Plus the act of
putting the code in a library and cleaning it up so it can live
in one is what is needed to actually make the code reusable.

The current architecture of LinuxBIOS (not counting the weird FILO thing)
works and does not leave us implementing an OS.  As we approach being
feature complete and quite general we accumulate a lot of code.  But
largely it is conditional upon what hardware actually exists on a
motherboard.

Another issue on this topic is what interface do we provide to the
outside world to people who want to customize LinuxBIOS.  The reason I
am largely in favor of testbios, openbios, ADLO and the Linux kernel
is those are interfaces that already exist.  Commodity interfaces you
might call them.  We don't have to convince hardware manufacturers or
software developers to support something new.  That makes the option
rom problem easier.

For embedded developers the question is what will work best for their
hardware and use the least amount of resources (to keep the price
down) while doing so.   So far LinuxBIOS has kept itself inside of 64K
for x86 which is doing pretty good on general purpose server boards.

As best I can tell there are two primary target configurations for
LinuxBIOS.  General purpose firmware that can do a lot of things.
Embedded systems where things are well enough understood you can
directly load your final image from flash.

Except for a few issues like romcc being a code size pig I think
we are ok on the minimal configurations.  For the general purpose
default configuration/configurations we still have a long ways
to go.  Etherboot when I proposed it was a stop gap that worked.
And we could use it immediately because of it's size.

Etherboot does not currently do everything we need.  It works but is
lousy at booting off of disks, for example.  There are a lot of
ways forward including enhancing etherboot, enhancing filo, or finally
getting the Linux kernel small enough we can use it.

So far I have been buried alive under the task of catching with the
latest and greatest chipsets and doing all of the required ports.  
I have not had much time to work on the bootloader problem recently.
I want people to understand the reason I have not followed through on
my ideas have been scheduling conflicts and not because of any
intrinsic problems with the ideas.  Except possibly the romcc size
optimizations :)

Eric