[coreboot] GSoC-2014 Project for Coreboot

[ron minnich]

We've been kind of holding off on this, but, fact is, coreboot has followed
the well trod path of firmware everywhere and become a small kernel. It
started as little more than memcpy with a frisson of I2C packet IO thown
in, but thanks to the generous ideas of hardware designers everywhere, with
ever-increasing needs for block IO devices, little on-chip packet networks,
and so forth, here we are: YAFOS (Yet Another Firmware OS).

LinuxBIOS/coreboot was intentionally not designed to be a kernel or become
a kernel, and the strain is starting to show as we find ourselves needing
to be more of what a kernel is. Alex points out that "The problem is
creating yet another API for accessing
stuff, besides which we'll add an MTD and NAND API, etc. etc. etc. This
would
make us EFI-ish."

I've been feeling the same way. Adding specific APIs for specific device
types is very old school design (and I mean REALLY old school, like OSes
from the 60s). That was always a major objection I had to EFI -- it looked
like the guys who designed it had never heard of Unix.

There's not much point in fighting the tide here. The idea of linux-as-bios
was nice, but we have come to the point where linux-as-bios requires a
small firmware kernel just to load it.

I think we need to step back from the small problems just a bit (i.e.
generic block device interface) and think about generic device interfaces.
It's doable: see Unix. We don't have as broad a range of devices as Unix
had to contend with (no paper tape). And we've got tons of different
examples to draw from.

But should this device abstraction be a driver or a device? And, in this
new world, would the driver/device distinction in coreboot disappear?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140314/f1411696/attachment.html>