On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
> * Kevin O'Connor <[EMAIL PROTECTED]> [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
_______________________________________________
Linuxbios mailing list
[EMAIL PROTECTED]
http://www.clustermatic.org/mailman/listinfo/linuxbios
