Greg Watson gwatson@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