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.
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:
1. 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?
2. 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?
Ollie