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. Jordan -- Jordan Crouse Senior Linux Engineer Advanced Micro Devices, Inc. <www.amd.com/embeddedprocessors> -- linuxbios mailing list [email protected] http://www.linuxbios.org/mailman/listinfo/linuxbios
