[PROPOSAL] extended payload handling

[Mathieu Deschamps]

Le dim 20/06/2004 à 18:23, Stefan Reinauer a écrit :
> * Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040614 11:07]:
> >  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.
>  
> This sounds interesting. How would that work? It's possible to load
> remote payloads with etherboot. Is that what you mean?

Brief State:
No but that's quite in the view, like the a modular approch.

Complete State:
IMHO, with what i've seen and read, I consider not the payload simply
as just an OS ...and well that the topic : extended payload handling. 

So maybe you'll say that now i've seek to far in the way. Ok, that makes
some reading but : 

-It is wide scaled and borrows from the good suggestions/needs of every
one.
 
-This design is really worthy when networking and if local,it needs some
sort of loopback. But it is admitted it networks.

-So... not oriented... but in favor of clustering and embedding rather
than others : anyway theses are the main application I think ?


 Let's move in deeper:
    
It seems clear it  to clarify the payload thing, even before saying we
are going to extend the payload handling.

During my works i couln't find clearly a definition of payload or rather
limitations. If I digested it well, actually, a payload is a polymorph
container of what is not Linuxbios-seemingly.

Moreover, it seems underway, drafts making almost everything a payload,
there is pro and cons, but i like this idea, suggest vastness...

Generally speaking, the good side is a part of project that's not
defined, has illimited lifetime, because it'll morph and adapt to
current needs. 

The bad is in the pratical coding and designing, that swinging nature
pouring into this needs/fonctions or that needs/fonctions leads to
unconstance properties, and this undef is bad to 'computing' common
sense :). It has to have some stablity to prevent deprecation.

The payload is some kind of concept that needs definition, to seize its
properties to fix them down. Ok enough foresaying, some of my
proposition are truely science fiction rather than operationnal, but
other don't. 

 			DRAFT EXTENDED PAYLOAD

 I see four... five properties for now :
	1-  Where/Spread   	  : internal, local or distant.
		its nature is pure internal to linuxbios or
		is local to machine or has networking capacities
		(single hardware component sharing : realtime payload 		 servers)

	2-  Who/Nature   	  : OS, BOOTLOADER or Core Program.
		A core program could be a bios hardware component init. code
(linuxbios components) or to-end-finality program like a
securisation/authentification protocole before booting OS.		

	3-  When/How long/Lifetime: 
		*Once  : instant use and kill and overwrite memory,
		*TSR   : instant use and teminated but memory reserved, 
		*Illimited : a real bios service (e.g.IRQ) always alife, 			    
memory reserved
	4-  How/Ressources	  : pure volatile, LB tables, distant. 
	5-  How deep/Intensity	  : raw i/o or bios init

 This properties combines to will to suit every needs.

 Basically, as suggested Ollie there is a Kernel, rather a core and...

	' - 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?'

... Yes shortly, that's what i like.

    It needs IPC or rather a abstract payload layer with a somehow
communication based upon the Linuxbios Table. Not as heavy as IPC but i
feel no shame getting inspired by that strong accredited
fondation?

    	The core has a programmed (boot sequence) tasklist definied for
example in the config file (with a somewhat order). So basically, you'll
asked the core to wait uppon the arrival of the payload containing the
code that initialize the controler, that boot the OS, or that is the OS.

	Whether it come from distant packets sendings or local. Ok for
now it is pure local-local... But in the near future ?  bootloader/Os
chain in Etherboot  is already distant and that a clue. The paylaod
architecture i propose should thus integrate this idea.

 Today's Pros    : some piece modular, somewhat easy to set but hard to
		   port
'Potential' Pros : interoperability, self-determined, 'intelligence'.

	Look by the time the Real Time Clock is set, it could know, after a
defined timeout has expired (because it cannot do it with local
ressource), that this core componant (core program ?) it tries to
initialize, has been done, onto another server. 

	Ok that lead to some fiction but that we are not that far of... so
maybe if the lan controler is init, and inter lxbios request layer (to
my mind here would be the real comparison with IPC) is set it could ask
to the foresaid server some assistance ? Why not reduce port to the
maximun and centalized it in the core ?

	But back to ground, the core indeed should contain memory managment,
cpu managment and  basic io to pci bridge, the rest should be modules
that are loaded upon linuxbios config file tweakings.

	Truely (a little) less that LB's core part does for now, so that there
would be low in-trash and full reuse and encapsulation. And the core
will have hat abstract payload layer that understand those declinaisons.


Fo examples, some scenarii and their corresponding attributions : 
	*You like your Linuxbios to initialize your SCSI controler :
		1- Internal (a Linuxbios component)
		2- Core Program (a module)
		3- Once (to boot os and then the kernel redo SCSI)
		4- volatile (here because once)
		5- bios init
	*You like it to init your graph chipset in order to display
	a linuxbios splashscreen.
		1- local
		2- Core Program
		3- Once/TSR depending what OS will set then
		4- volatile/LB table
		5- raw i/o or bios full init
	*You like to choose etherboot to be you bootloader it is
		1- distant
		2- bt ldr
		3- depends if you what to have some session like
		handling but normally it should be Once
		4- LB table/distant
		5- raw i/o or bios init


ok, anyway it is a draft... again that
is long ...


mathieu.



> 
> >  and I too, have to say sorry if I confused the thing, but i feel like
> > this needed to be said.
> 
> I appreciate your sometimes flowery way of describing things even if it
> is hard for me to follow (which is due to my lack of french knowledge,
> when it comes down to your fine document)

 ha ah.. Thanks.. i'am part of people that thinks, 'smiling' while
reading a 90 pages long technical document is not a luxury...
it is a compulsary ;)

> 
> Stefan
>