I agree with what is said here, except if I may...
I need to react to your questions and This topic is NOT a question of purity of code or of something nor only a policy... Brief : this is a stacke...
But let admitting that the question of extending the payload handling seems central and IMHO Linuxbios cannot spare this evolve.
This still lives, provided it doesn't jeopardize theses fondations (and i think these are still goals):
-LinuxBios is govern by the less possible code writing (letting Linuxbios be truely an OS would neck twist this at very short term)
-LinuxBios aims no specific target or rather potentially everyone (architecture as application field of this technology)
-LinuxBios is to answer to the lack of 'modernity' of common BIOS, to answer to nowdays applications, theses BIOS :
-support old DOS fonctions we don't want, theses are useless for non-DOS-based OS, and they are more and more present. (again shall we, not to redo what DOS have done and now we don't need nor want ?)
-are based upon the executant/orderer scheme as mirror reflection to the master/slave scheme of the hardware controler, this approch leds to ennoying limitations and has rise norms and rules which asserves rather than they freed.
This scheme *was* logical, and inspires straight in the line the old net working style, in the same relationship of communication.
Since the begining, 20 years ago, the interconnection of net , changed that old scheme to new one though at this time they couldn't figure how up this could led (or maybe could they)
My questions:
Would we return that new scheme to the oldiest part of a computer ? (further in) Is this good to be inspired by that scheme and return it back in the opposite way out ?
Considering this and letting myself, just for the fun, being affimative twice here is my reflexion :
With the networking growth and the all-communicative state of the demand and its consequence, interoperabilty; can't LinuxBios implements an upper abstraction so to take over the forsaid scheme and answer in the whole to that demand ?
Precisely, That demand is wide spread and, to get Linuxbios customized to this or that type of application (whether it's for clustering or embedding or whatever) without requiering week of port or customing is impossible as it goes.
There is another way, to the 2 mentionned there after (fore admitting the second is a one :)
As payload can be distant or local, why not handling payloads as modern network handles packets ? I know this could sound wierd or crazy but to my sense it is not.
and I too, have to say sorry if I confused the thing, but i feel like this needed to be said.
mathieu.
Le ven 11/06/2004 à 18:24, Li-Ta Lo a écrit :
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:
- 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?
Ollie
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios