Li-Ta Lo ollie@lanl.gov writes:
On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
- Kevin O'Connor kevin@koconnor.net [040610 06:09]:
If I understand your proposal correctly, one of the major issues will be ensuring that the payloads don't step on each other or linuxbios when they run.
Yes, mostly. They must not overwrite LinuxBIOS in memory. And there needs to be a mechanism within linuxbios that allows to execute many of them.
Wouldn't it be simpler to just link linuxbios and all the payloads together at compile time? Essentially, that is what your proposal is doing, except it does it at run time.
(What I am going to say proabably will offense a lot of people. I have to say sorry in advance.)
The reason we are having this discussion is due to some POLICY, someone does not want these MECHANISMs to be linked with the CORE LinuxBIOS to jeopardize the PURITY of it. The only way to hold this POLICY and to maintain the PURITY is to seperate these MECHANISMs out and use ELFLOAD as firewall.
Exactly whenever you change the interface as visible to the outside world of a piece of software you need to examine very closely what you are doing and to discuss it. Things are much more serious, and the consequences are much more significant than a purely internal change.
Especially something like firmware that people are reluctant to touch after it works.
This project/software is going to be exactly as what I predicted a few years ago: it is going to be an OS. Well, it is not that bad as the original idea of LinuxBIOS is to use an OS to boot an OS. The question is who is who and which is which. The discussion I have read so far can be categorised into these two:
- Monolithic v.s. Micro Kernel - do we want to put and link
everything into one program or as seperated PAYLOADs (processes/servers?) and use some complicated Inter Payload Communiction (IPC) to exachange information and reuse implementation?
- Reimplementing an OS called DOS - I read topics about the
order of loading PAYLOADs and how or should they overlay each other. I also found people talking about something as Terminated but Stay Resident (TSR). Sooner or later we will face the problem of 640K and the solution would be HIMEM.SYS.
Before we going to discuss this any further we should ask ourself, do we really want to go this way? History probably repeat it self or not, but do we want to repeat the history?
I don't think we want to becoming an OS.
History happens to be easy to repeat because people are familiar and comfortable with it.
From what I can tell all of the messy corner cases come from people
wanting to implement some form of code reuse. And to reuse code things must share and cooperate.
I will argue that if want code reuse someone should be a library of the functions that will be reused. Then we don't need multiple PAYLOADs and all of the associated nastiness. Plus the act of putting the code in a library and cleaning it up so it can live in one is what is needed to actually make the code reusable.
The current architecture of LinuxBIOS (not counting the weird FILO thing) works and does not leave us implementing an OS. As we approach being feature complete and quite general we accumulate a lot of code. But largely it is conditional upon what hardware actually exists on a motherboard.
Another issue on this topic is what interface do we provide to the outside world to people who want to customize LinuxBIOS. The reason I am largely in favor of testbios, openbios, ADLO and the Linux kernel is those are interfaces that already exist. Commodity interfaces you might call them. We don't have to convince hardware manufacturers or software developers to support something new. That makes the option rom problem easier.
For embedded developers the question is what will work best for their hardware and use the least amount of resources (to keep the price down) while doing so. So far LinuxBIOS has kept itself inside of 64K for x86 which is doing pretty good on general purpose server boards.
As best I can tell there are two primary target configurations for LinuxBIOS. General purpose firmware that can do a lot of things. Embedded systems where things are well enough understood you can directly load your final image from flash.
Except for a few issues like romcc being a code size pig I think we are ok on the minimal configurations. For the general purpose default configuration/configurations we still have a long ways to go. Etherboot when I proposed it was a stop gap that worked. And we could use it immediately because of it's size.
Etherboot does not currently do everything we need. It works but is lousy at booting off of disks, for example. There are a lot of ways forward including enhancing etherboot, enhancing filo, or finally getting the Linux kernel small enough we can use it.
So far I have been buried alive under the task of catching with the latest and greatest chipsets and doing all of the required ports. I have not had much time to work on the bootloader problem recently. I want people to understand the reason I have not followed through on my ideas have been scheduling conflicts and not because of any intrinsic problems with the ideas. Except possibly the romcc size optimizations :)
Eric