It doesn't matter. The type number space is per-name. It doesn't make sense
to look at the type without first looking at the name, so it doesn't matter if
different names reuse the same type numbers.
>> > elf. Someone could add it to a.out or to some new format. Also I disagree
>> > that you can totaly guarentee that all future formats will totaly
>> > compatible. I think that you should allow for multiple versions to be
>> > placed in the notes section and then search for the one which you
>>
>> I believe that I can guarantee enough compatibility. In the _worst_
>> case, I will end with (I believe that will never happen
> Maybe we should use a Major and Minor version scheme of sorts.
> Change the major if there is a strong change backwards compatible.
> Change the minor for smaller changes.
>> > understand. Our structures really are similiar enough. Also for the
>> > version field I really like encoding the date in there as a version
>> > number.
>> You are having year-429496 problem with your date encoding, through
>> ;-))))). (I do not much care what encoding of version you use. It has
> Actually it should be looked into before the year 9999 AD
> I'll make the date the minor version, then sometime before 9999 they can
> raise the major number and expand that one field. I hope that 32bit
> computers are really considered obsolete way before 9999;->
The common approach is to include the size of the structure within the
structure itself. If you add new fields, add them to the end. If you want a
field, make sure it exists in the structure. You only need to worry about
major version changes if you change the meaning of a field within the
structure.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/