RFC tagged payload

[Eric W. Biederman]

steven james <pyro at linuxlabs.com> writes:

> Greetings,
> 
> 
> I've been working with a tagging system so that multiple payloads in
> firmware can be selected from serial at boot time.
> 
> The scheme adds a 16 byte tag block in front of each payload containing a
> $TAG$ signature, additional block count, a payload length (optional, may
> be 0), and a name string.
> 
> The idea is to search for tags in the ROM, present the name strings in a
> list and allow selection of a particular target. The stream is then
> positioned just past the tag and passed to elfboot.

My memory is that tags don't rewind, because it could be something
like a serial port...
 
> changes:
> elfboot no longer calls stream->init(), it presumes that has been done
> already.
> 
> add stream methods:
> searchtags
> gettags
> loadtag
> 
> search tags performs the search and specifies the neded buffer size to
> hold the result.
> 
> gettags loads the tags into a provided buffer for presentation
> 
> loadtag positions the stream just after the selected tag index (0 based)
> 
> for backwards compatability:
> Where no tags are found, the stream is positioned at the beginning
> 
> where the stream->searchtags == NULL, presume the stream object doesn't
> support tags. Just call init and pass it to elfboot.
> 
> Yes, No, Comments?

The tags can be done as ELF notes, so an extra header is unnecessary.

Whatever happens in LinuxBIOS itself should be non interactive,
and unconditional.  There are a whole lot of ideas about interactive
bootloaders, and accepting them all into the core opens us to all kinds
of bloat and feature creep.  So the interactive code needs to be a
seperate payload.   

If it can be done without penalizing the rest of the code it is ok to
put that ELF payload into the tree.  But not into the core.

Eric