Eric,
Maybe someone add some build instruction for Etherboot for LinuxBIOS would solve the payload building problem.
Regards
YH
-----邮件原件----- 发件人: linuxbios-admin@clustermatic.org [mailto:linuxbios-admin@clustermatic.org] 代表 Eric W. Biederman 发送时间: 2004年6月8日 1:04 收件人: LinuxBIOS 主题: Bootloaders and LinuxBIOS
As the freebiosv1 tree grew and developed we had a lot of disagreement about bootloaders. What should linuxbios do in condition X. It was clear that there was no way that in the linuxbios tree itself we could satisfy all of the developers. You can see remnants of this in the freebios1 tree in src/lib/linuxbiosmain.c
Coming into this confusion I proposed a truce, that would give us greater flexibility and allow a single LinuxBIOS source tree for everyone. That was to have a really stupid bootloader in LinuxBIOS that was smart enough to load a real bootloader. That is where elfboot comes from.
To prove my concept I ported etherboot to run under LinuxBIOS as that was the only bootloader I could find that actually had real hardware drivers. In this scenario the fact that etherboot well with my style of booting was no longer a threat because people were free to use their own code. Etherboot was also choosen because of it's strong core team of maintainers and you can all see the results of that decision today.
Out of this concept we had additional bootloaders written or ported: ADLO, FILO, OpenBIOS, baremetal, linux kernel, etc.
So from everything I can see this concept has been a success. I have seen no complaints. We don't have more because it is not the easiest thing to write standalone code to the bare metal. But this is something time and starting to catch up on our LinuxBIOS ports has been overcoming.
One of the large reasons I was a great proponet of the simple/stupid bootloader in LinuxBIOS to load a real one is that draws a line around what functionality LinuxBIOS shall provide. Anything over that line is code bloat.
Several months ago as I was involved in other things Yhlu noted that FILO had been added to LinuxBIOS without a word. The way he described it I thought it was as a driver to elfboot. I expressed my concerns at that time, but I really have not had time to do anything. And if it was a driver it was seriously pushing the line I had drawn against feature bloat, and really coming close to starting another bootloader feature war but it was perhaps ok.
Later I finally had time to start syncing my code with the main LinuxBIOS and I saw what that code actually was, and I was shocked. This code had crossed the line, it had broken the truce, it was feature bloat. Not to talk about how useless a disk based bootloader is without a configuration file. From that moment on I have not seen a reasonable solution besides deleting that code from LinuxBIOS.
Last time we had this conversation 2 problems were mentioned that this code solves. 1) People have a hard time setting up an external payload. 2) There are not any bootloaders for the ppc that run under LinuxBIOS.
To the problem of setting up an external payload I propose we can include FILO into the tree like baremetal and simply make it the default payload. If you don't change anything it will get built. That solves the problem without breaking the design.
To the problem of there not being any bootloaders for the ppc that run under LinuxBIOS. I respond that one of the x86 based bootloaders would not be hard to port, or better yet we can just use a kernel with kexec built in. Although I would strongly be with the amount of embedded activity that happens with the ppc if none of the native ppc bootloaders could not be easily adopted.
In addition I have seen noone except the guys at LANL who are even interested in the built in FILO.
I have a few additional technical objections as well. Just like when someone tried to include etherboot the code in the LinuxBIOS tree has languished, and is much less capable a solution.
Having to support bootloaders places an additional burden upon the LinuxBIOS code that must be considered when the code must be refactored or cleaned up. And we have not even succeed in a sufficiently clean and stable API that we are willing to freeze the core interfaces and make stable releases from the LinuxBIOS tree, only adding new ports or extensions to the existing API that cannot possibly break old ports.
So does someone have a reason to keep the built-in FILO besides being lazy slobs who want something-for-nothing and are not willing to put in the work to make production quality solutions?
Eric _______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios