On 4 Apr 2004, Eric W. Biederman wrote:
Personally the one I want is based on a real live kernel. And if I can get some time that is what you will see.
Sure. That's where I started this project from almost 5 years ago. We only have this plethora of bootloaders (etherboot, filo, 9load, etc.) because our initial goals of a real live kernel proved techincally impossible -- flash was too small. 2.6 + bigger flashes might put us back where we were 4 years ago with the L440GX+ boards, with 1 MB flash and a 2.4.7 kernel that easily fit in that space. We can hope so.
IIRC you and I had some discussion on this several years ago, on this list, and you were firmly in the Etherboot camp, as you thought the small fast Etherboot kernel had advantages over a full live Linux kernel. You made some excellent arguments in favor of this idea. I argued that the Etherboot approach was fundamentally flawed, and that in the end I wanted a live kernel in there for booting. We agreed to disagree. So I'm glad to have you back :-)
Just kidding. You and I both know the excellent Etherboot work you did was a real accomplishment and definitely saved our collective necks.
But: you have to at some point consider what people are asking for, and we do think about that as we get a lot of requests here not reflected to the list.
Some ongoing requests: VGA that works in linuxbios, and a boot prompt that can allow a user to type a pathname to a CD image and do an install. One build, not two or three. And people want it in one package. The requirement with the current setup to build multiple binaries such as Etherboot at present can't do this. Greg's test integrated FILO can. We also need the emulator in linuxbios because that is the only practical way to get to this demand. And it's got to be very very small. Some of the recent changes in V2 have been tough on the embedded folks, and that is of real concern to us. Please bear in mind that you folks at LNXI are not as affected by the embedded world as we are down here, and I have had a number of comments about V2 in that regard.
Hence these trial changes. Plus, a simple fact: if you don't like them, don't enable them. Nobody's locking them in. We are making them available to those who can use them. The goal is flexibility.
We've also had lots of people with issues with the ELF loader approach. Requiring an ELF target is requiring a policy as near as I can tell. Many people don't want to deal with mkelfImage, esp. as it has proven to be non-portable in some cases (maybe this can be fixed, but if you mkelfImage on a 64-bit K8, etherboot coughs and dies in the elf loader -- there are issues).
Also, re this: "In addition we have had way to many questions of what is the right policy for a bootloader to implement, on this list. I refuse to couple that to the LinuxBIOS core. And I don't want some stupid policy in there like FILO's that would require me to upgrade my firmware just to upgrade my OS. "
To most people, the distinction between "payload in flash" and "linuxbios in flash" is immaterial. In other words, these folks don't care about the seperation between LinuxBIOS and payload! they are much happier with an integrated one-step system that boots an OS. What they want is to be able to install from CD. Etherboot won't let them do this, and neither will an ELF loader. Integrated Filo gives people something they can use today, that will be easy to build.
Finally, let's remember that the ultimate goal of a project such as LinuxBIOS is utility, not beauty and beauty alone. Sometimes what some people consider beautiful is sacrificed in order to support needs of customers. Let's not go so far into concern for beauty that we forget that lesson. I'm maxed out on 'beauty uber alles' on the Plan 9 list.
Anyway, before this conversation gets too hot, please everyone take a deep breath, remember your email etiquette, and don't forget we are all friends here. It's important to resolve these issues in an atmosphere of cordiality.
ron