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