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:
- boot support for traditional BIOS / EFI driver
- Windows drivers
- 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:
- use Linux in FLASH to load OS from disk
- 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