[PROPOSAL] extended payload handling

[Eric W. Biederman]

Greg Watson <gwatson at lanl.gov> writes:

> Stefan,
> 
> I think this is a reasonable idea, particularly your suggestion of making
> linuxbios more modular. One of my main beefs with the payload strategy is that
> each payload has to provide it's own set of, potentially buggy, driver code. If
> we have 5 payloads then we have 5 sets of drivers that all do the same thing
> slightly differently. If the drivers were modular enough so that a payload could
> call them directly, then this would go a long way to addressing these concerns.


The historical perspective on this is interesting.

On the alpha there is/was a bootloader known as MILO.  MILO reused
kernel drivers directly from the kernel build tree.  I think
this was actually inspired by the design of the SRM as I have
heard the SRM uses VMS drivers.  Anyway in practices MILO was
tied to a single kernel version from which it could uses drivers.
In theory MILO was only tied to a kernel major version, but
even switch to a kernel with a different minor version was a pain.

Then look at etherboot or oskit or u-boot, or the BSDs just about any
project that has it's own set of native hardware drivers.  They work
and evolve and are not unmaintainable relics before their time.
Between related projects you will often seen code sharing or being
heavily influenced by other projects but never direct code reuse.

Given that code reuse is a mantra in some circles of the software
world.  That sharing fails and not sharing works appears
non-intuitive.  I can only guess about the reasons for this but here
are a couple.  Writing reusable generic code is at least 3X as
difficult as writing code for a specific purpose, and most driver
code is not designed to used directly in multiple projects.   By not
sharing code directly reasonable expectations about the difficulty of
adding new features are set appropriately.  

Another way of looking at it is that synchronization and coherency in
the large is hard.  Things scale better by having their own private 
resources instead of shared resources that can't scale.  This appears
to apply to software source bases as well as hard drives, memory, and
the like.

Eric