[PROPOSAL] extended payload handling
Eric W. Biederman
ebiederman at lnxi.com
Mon Jun 14 13:49:01 CEST 2004
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
> 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.
More information about the coreboot