[PROPOSAL] extended payload handling

[Mathieu Deschamps]

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 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.
> 
> 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
> Linuxbios at clustermatic.org
> http://www.clustermatic.org/mailman/listinfo/linuxbios
>