[PROPOSAL] extended payload handling

[Eric W. Biederman]

Li-Ta Lo <ollie at lanl.gov> writes:

> On Fri, 2004-06-11 at 06:27, Stefan Reinauer wrote:
> > * Kevin O'Connor <kevin at 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:
> 
> 	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?

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.