Le dim 20/06/2004 à 18:23, Stefan Reinauer a écrit :
- Mathieu Deschamps mdeschamps@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