* ron minnich rminnich@gmail.com [070828 18:11]:
On 8/28/07, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
OK, so I was unclear. The idea was to number the payloads as well, not only the segments.
Let's hold off on that, it will require a lot of changes, and it is not really what we planned. We have normal and fallback; there is really nothing in the design for normal0, normal1, etc.
We don't even have normal and fallback at the moment. And I doubt it will come back, except artificially.
I think we have two choices:
* either fallback becomes _really_ stupid and just tries to load a payload via ymodem
* or fallback/normal is linuxbios and has nothing to do with the payload. So N linuxbios images (N=2.. normal and payload) will be able to load M (might be 2, but no requirement) payloads.
We simply could reserve some space at the end of the header and use that for future extensions without having to change a version number. Only if the extension needs changes in earlier fields of the struct we would have to change the MAGIC.
It gets messy. We'd have to implement version # management in lib/lar.c, and I think that's a different coding discussion which I would rather not include in this patch.
The simplest version management you could think of:
if (lar_version > my_version) { printf("Your image is too new. upgrade lar utility\n"); exit(1); }
if (lar_version > my_version) { printf("Your image is too old. downgrade lar utility\n"); exit(1); }
or even
if (lar_version != my_version) { printf("Your image version and lar utility version do not match. Change either\n"); exit(1); }
Anything beyound the above is a waste of precious time imho. Let's not do migration paths for pre-pre-pre-pre-pre-production software.
Stefan