[LinuxBIOS] ELF loader in v3
jordan.crouse at amd.com
Mon Jul 2 16:53:58 CEST 2007
On 30/06/07 16:32 +0200, Uwe Hermann wrote:
> On Fri, Jun 29, 2007 at 10:55:25PM +0200, Stefan Reinauer wrote:
> > I think we really want to freeze lar in the long or even short run. we
> > should get this finished within the next few weeks. Lets not freeze or
> > version the format during development. If early versions stop working at
> > some point, that is not an issue. We dont run on any hardware, yet.
> > Decompression is the only issue I see with this at the moment. :( It
> > will make us have several copies of the same stuff again :(
> We definately need a version field in the lar header, we probably cannot
> use the same format forever, there _will_ be changes one day.
Agreed. Stefan and I discussed this briefly at OLS.
> I agree that we don't have to worry too much as long as there are no
> external users (yet). But in fact, the 'lar' binary itself will be an
> "external" user. It will be available from /usr/bin/lar or similar,
> as a general utility (_not_ bound to a specific revision of LinuxBIOS).
> We'll use 'lar' to add entries (e.g. payloads) to existing images, remove
> entries, etc. etc., all from user space with the 'lar' tool.
> Thus, this tool must know which version of a lar archives it works on,
> and it must contain backwards compatibility code, to not only handle
> the lar format which was the newest one when the tool was compiled,
> but also all older version (at least those, which were "released" or
> marked as "stable" or something)...
> For now the work required to do this is almost zero, just add a
> 'version' entry to the lar header struct and ignore it's value.
> Later versions will have to read the version field and act accordingly.
I think now is the time to do that - we can easily break any lar users
now without much penalty. Later, it won't be so easy.
Senior Linux Engineer
Advanced Micro Devices, Inc.
More information about the coreboot