[PROPOSAL] extended payload handling

[Stefan Reinauer]

* Mathieu Deschamps <mdeschamps at mangrove-systems.com> [040608 17:52]:
> > Not really. It works because the payload you use is a bootloader. This
> > is a very hard restriction, as PCI resource allocation, or testbios are
> > no bootloaders, and thus do not need and should really not have an ELF
> > loader like LinuxBIOS itself has.

>  oh right... same when you build a the hello world example to test
> LinuxBios boot time : it no a boot loader. It is a ... I realized
> this difference i've reported it as bootloaders and booters. But I don't
> know if it's a good name... what do you think ?

I think just "payload" is fine in LinuxBIOS context. Or, since it's not
an intermediary it might be considered an OS or just a lowlevel
application.

> > Optimistically, LinuxBIOS itself, without PCI resource allocation 
> > should only eat up around 32k with some fiddling. Compared to 256 or
> > 512kbyte flash devices there is plenty of room for additions. If not
> > ADLO then something else.
> 	yes. but no to forget the VGABIOS that's 64k also or rather 50k
 
Except for onboard graphics adapters this is placed on the graphics card
rom and does not need to be packed into the system rom.

> > * if we decide, that having FILO inside of LinuxBIOS is a break in 
> >   design, we should be consequent and split everything but DRAM init 
> >   and ELF loader out, including
> >
> 	So if i'am not mistaking, this would leave a LinuxBios core very thin
> while 'modules' adding fonctions, facilities and commodities would 
> make it thicker...  an architecture that has proven it efficiency...
 
Yes, exactly. Commercial BIOS does a very similar thing, and of all
things commercial BIOS does, this is actually among the best.

> > * payloads should be able to leave information in the LinuxBIOS table,
> >   so that following payloads don't have to do the same work over and
> >   over.
> 	yes . if it's the role a the LinuxBIOS table...hum sure it is.
 
The LinuxBIOS table is an enhancable table that can have new entries
defined without breaking the parsability of old well-known entries. If a
payload does not know how to parse a LB table section created by
LinuxBIOS core or another payload, it would automatically simply ignore it.

> > I see a certain point in not having function callbacks, even if I think
> > it's a dubious one in a full open source environment, but I am not going
> > to argue about this. It's not really needed, EOD.
> 
> 	for now, i also can't see the use of such a possibility... 
 
Well, console output, memory management and all of these have to be
realized by every payload itself, thus producing a small code overhead.
While offering the ability to make things self contained and thus solid,
it also contains the possibility to include new bug sources.. It's
really philosophical in an open source project and there's lots of other
things to do.

Stefan