<div dir="ltr"><div class="gmail_extra">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).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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 "<span style="font-family:arial,sans-serif;font-size:13px">The problem is creating yet another API for accessing</span></div>
<span style="font-family:arial,sans-serif;font-size:13px">stuff, besides which we'll add an MTD and NAND API, etc. etc. etc. This would</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">make us EFI-ish." </span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">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. </span></div>
<div><br></div><div>But should this device abstraction be a driver or a device? And, in this new world, would the driver/device distinction in coreboot disappear? </div><div><br></div><div>ron</div></div>