[LinuxBIOS] A very good idea

[Al Boldi]

ron minnich wrote:
> As to this OFW and LinuxBIOS discussion: LinuxBIOS is designed to load
> an OS from FLASH, no more and no less. To the maximum extent possible,
> LinuxBIOS avoids drivers, file systems, network protocol stacks, web
> servers, icons, GUIs, video displays, and so on. There is a reason for
> this: I have seen, over the years, that BIOSes tend to do a poor job
> of supporting hardware; conversely, OSes like Linux do a very good
> job. Hence the original design goal of LinuxBIOS: to facilitate
> placing a Linux image in FLASH, and using Linux as the BIOS. Hence the
> name.
>
> In fact, in the early days, we did not consider what we now call
> "LinuxBIOS" as separate from a Linux kernel. The payload was always
> Linux. The only thing that required the seperation, eventually, was
> the small FLASH sizes and the Linux kernel bloat.
>
> OFW is also an OS, really like Linux in a way. In fact, OFW is much
> more like Linux than it is like LinuxBIOS. It has drivers, file
> systems, console interaction, network protocol drivers and stacks (and
> now, even an 802.11 stack and OFW supplicant), a simple GUI, icons,
> interrupt support (in some versions), etc. etc. Some implementations
> have had threads and/or processes. OFW seems to really want that
> console interaction -- the standard fallback is an 'ok' prompt. In
> many situations, however, console interaction is impossible, which has
> been an issue with clusters I have built based on OFW-based systems
> (i.e. SPARCs).
>
> That's one reason that LinuxBIOS is <32K, and OFW is 32K*10 -- even on
> a trivial platform like OLPC. OFW does a lot more. The extra
> capability of OFW makes it very powerful, and that is both a strength
> and a weakness.
>
> There are two things that OFW does that I am uncomfortable with. The
> first and most important is, as mentioned: it has lots of drivers. If
> you are planning to run, e.g., OFW AND  Linux on new hardware, you now
> have doubled the task of writing drivers: you get to write BOTH Linux
> and OFW drivers. Now, people tell me all the time that drivers are
> easy. Generally, these are people who are either really good at
> writing drivers, or who have never had to wring the last
> almost-never-happen bugs out of a driver. It is true that the first
> iteration of a driver is pretty easy. What makes them miserable is
> managing all the corner cases and hardware bugs and
> only-happens-once-in-100 million iterations bugs. So, for example, one
> of my OLPC units will still not talk to ANY of my flash sticks ...
> from OFW. From Linux, these flash sticks work fine -- and always have.
> They worked fine when we used Linux-As-Bootloader. Yep, this can be
> fixed, but it does point out the issues that come up with supporting
> two different operating systems on one piece of hardware. Each one has
> to work, and they have to interact and work together. It's more than
> twice as complex, because of those interactions, as Jordan alluded to
> in a recent note.
>
> The drivers require support, but the support team for OFW is probably
> 1/1000 the size of the support team for Linux, and, I guess, has about
> 1/1000 the money to do the work -- I think this is an optimistic
> estimate. So, which group will fix bugs faster, and be more current on
> hardware? I think I can guess. That's why I like Linux as the BIOS. It
> gets back to support.
>
> I don't believe that OFW will ever have the level of support that
> Linux has. It is an OS, but it is not the OS people run; it just boots
> an OS. That distinction is guaranteed to put OFW behind Linux in the
> queue for support money and people. And, further pressure applies,
> because the chipset vendors are making it very clear to third-party
> vendors that their BIOS support teams should be writing EFI drivers,
> not OFW or other BIOS drivers. Whatever time and money the hardware
> vendors have for driver writing breaks down something like this:
> 1. boot support for traditional BIOS / EFI driver
> 2. Windows drivers
> 3. Linux (maybe) drivers (you can tell by the quality of some of these
> drivers ... )
>
> I've seen this directly. We talked to one company, who told us they'd
> be showing us some really neat cluster hardware "as soon as we have
> finished up our EFI drivers". Yes, they are writing EFI drivers from
> scratch, although they have existing Linux drivers. Why not boot Linux
> from FLASH? An interesting question. It would require some chipset
> vendor support, I suppose. :-)
>
> I talked to someone yesterday who built a small OS for an infiniband
> appliance. They actually got it to go. They also swore that the next
> time, their firmware was going to be simple: "Load Linux from flash
> and go -- let Linux do it". That's been our rallying cry from the
> beginning -- let Linux do it.
>
> One might ask, instead of merging LinuxBIOS and OFW, why not merge
> Linux and OFW? After all, we have shown that we can boot Linux from
> FLASH, and it can be fast. Linux has great driver support. Linux has a
> huge support team, and support from many corporations. So why not
> subsume OFW into a Linux module? I think this could work, for people
> who really want OFW, and makes more sense than merging LinuxBIOS and
> OFW.
>
> I think, for the future, where small 512KiB flash parts exist, the
> LinuxBIOS+OFW combo makes sense, for those who need OFW capabilities.
> And, as we have seen, on a sufficiently simple platform such as OLPC,
> OFW can do a great job without LinuxBIOS. I could post the OLPC
> startup code, I guess, but it's really a loop something like this:
>
> for(i = 0; i < COUNT; i++)
>    wrmsr(table[i].msr, table[i].value);
>
> Done. It's a tad more than that, but not by much. Few platforms are
> this simple.
> It's also quite possible that the OFW guys will get motivated to
> support K8 -- you never can tell, and the OFW people are very smart
> people.
>
> But, even if OFW ran on everything LinuxBIOS ran on, the OFW problem
> remains. OFW is a small OS, but it is an OS. If OFW is to boot an OS,
> such as Linux, then it will need the platform drivers. Let's suppose
> that OFW is ported to a mainboard such as the MS9185. It would have to
> support a lot of devices, and they would all have to be written. From
> what I can see, a given OFW port to a platform is far more complex
> than a LinuxBIOS port, due to the driver issues.
>
> Were OFW to grow, it would require the level of support required of
> any OS. It will never get that level of support, period. I actually
> find that regrettable. OFW would have been a far better path to take
> than EFI. I have never understood the decision, given the existence of
> OFW, for the creation of EFI (well, actually, I do understand it, and
> that's almost worse than not understanding it ... ). But that decision
> has been made, and we are not going to be able to reverse it.
>
> We might suppose that a company or companies would step forward to
> support and use OFW
> instead of EFI. The question is, how much support should a company put
> into an OS which is merely there to boot another OS? Or, to put it
> another way, given two choices:
> 1. use Linux in FLASH to load OS from disk
> 2. use OFW in FLASH to load OS from disk
> which one makes more sense, economically, including costs of support,
> documentation, and training? I've talked to a number of companies on
> this issue. Last summer, I offered one company OFW; the company knew
> what it was, and the response was immediate and negative; "No OFW. Put
> Linux in there. Our people know what it is, we don't have to train
> them on it".
>
> My second concern is that OFW also makes what I think is a mistake, in
> that it supports callbacks into OFW. BIOS callbacks made sense in the
> 1970s. They even made sense into the 1980s. But as of the 1990s, when
> NetBSD on SPARC came out, one of the big NetBSD improvements over
> SunOS was to REMOVE the OFW callbacks for console I/O, i.e. to reduce
> the use of OFW callbacks. I am not convinced callbacks make sense any
> more.  We have seen on many thousands of platforms that we don't need
> them.
>
> BIOS callbacks complicate OSes in situations such as SMP -- you have
> to make sure the BIOS itself is SMP-safe, or you have to do nasty
> things in the OS to support the non-SMP-safe BIOS. I've seen systems
> with BIOS callbacks that were not SMP-safe (early EFI machines) and
> debugging them was quite hard. It would be nice to use the use of BIOS
> callbacks decline, rather than increase. The latest OFW patches to the
> kernel institutionalize the BIOS callbacks used on OLPC. I wish that
> had not happened.
>
> BIOS callbacks also complicate virtualization (think Xen and friends).
> A privileged OS (domain 0 in Xen) can make those OFW calls, but how do
> you manage domain 1 and up OFW calls? It is surely a Simple Matter of
> Programming, but do we really need to add this complexity to what is
> already a pretty complex world? I would rather not.
>
> Of course, the "guest domains" can just figure out they can not
> callback to OFW, and get the information some other way. But if an OS
> can get what it needs without a callback, why add a callback? Why add
> something to an OS when you can do without it?
>
> So, by all means, LinuxBIOS can be bundled with OFW. I think it can be
> a useful combination, for situations where there is not much FLASH
> memory. That situation is becoming less and less common, but it still
> exists .
>
> While I think OFW as a payload makes sense in some situations, I don't
> see much value in a codebase merge. LinuxBIOS with OFW is useful.
> LinuxBIOS without OFW is useful. So, we need to be able to make OFW
> optional. That "optional" nature makes a strong case for OFW as a
> payload.
>
> At the same time, I believe that as the FLASH sizes grow to 2 Mbytes
> and beyond, putting Linux in FLASH will be the preferred option for
> many situations. That mode is already common in the non-x86 embedded
> space. It's probably the fastest way to boot Linux. And, from my
> measurements, Linux is a very fast bootloader -- on processors running
> at  2 Ghz, it's the fastest by far. So for people who really want OFW,
> maybe an OFW kernel module or OFW shell makes sense, running as part
> of Linux. If OFW were integrated into Linux, the driver issue would
> disappear.
>
> Long term, however, I can not see the need for anything as complex as
> EFI or OFW when one can boot Linux directly, and have Linux boot
> Linux. At the FOSDEM conference a number of speakers showed Linux
> booting in well under a second -- this on a rather slow ARM. There's
> no fundamental reason that we can't boot Linux quickly and use it as
> either our embedded OS or bootloader.
>
> To put it another way, the "LinuxBIOS or OFW" issue is the wrong way
> to look at the problem, in my view. LinuxBIOS and OFW work quite
> nicely together, as we have seen. It's an OFW or Linux issue. Which
> one would you rather interact with at boot time? I think, in some
> cases, the answer is "OFW", and in other cases, the answer is "Linux"
> or "Filo" or something else. Increasingly, however, I think the x86
> world will follow the path of the non-x86 world, and the answer will,
> increasingly, be Linux -as- BIOS, which means Linux in FLASH.

Thanks for this 200+ line explanation.  I did read it all, which probably 
means that you were rather concise.  

Now, if I read you correctly, you are implying that OFW has overhead that 
isn't needed to just boot another OS.  And LinuxBIOS is a mini BIOS that is 
tagged onto Linux to leverage its driver pool.  Your point is taken.  But 
there is one point you didn't mention:

	OFW is pluggable, which means that it is easily extensible.

1. OFW in itself does not do anything other than provide a framework for 
pluggable firmware.  Knowing how big this empty framework is, defines its 
overhead.  Do you know how big it is?

2. OFW provides services via plugins.  These plugins can be anything, even a 
linux kernel, provided it's adapted to conform to the OFW api.  This means 
OFW can easily leverage the linux driver pool without providing any drivers 
itself.

3. OFW can easily host a Hypervisor as a plugin as well.

4. OFW can also relegate low level BIOS operations to a LinuxBIOS plugin, 
again provided LinuxBIOS is adapted to conform to the OFW api.  But, as the 
OLPC project has shown, they chose to implement this from scratch as it was 
probably much easier that way.  Which makes me think that we can learn 
something from this, and adjust LinuxBIOS to merge with OFW, while still 
allowing LinuxBIOS to act in a standalone manner, using a stripped OFW host, 
for cases where full OFW overhead is too big.


Thanks!

--
Al