Messages in this thread | | | Date | Wed, 19 May 1999 17:29:49 -0700 (PDT) | From | Jeremy Fitzhardinge <> | Subject | Re: format of elfcap header [was Re: Capabilities done right [di |
| |
On 19-May-99 Y2K wrote: > One request I make of you is could use you something like NT_KILL_CAP > which I shall probably rename to NT_BIN_CAP_KILL last I saw you are > were using the value 1 for n_type which is being used by NT_PRSTATUS. > I choose the value 7 for NT_KILL_CAP but I wish Jeremy Fitzhardinge > would comment on if they are any current numbering systems for ELF NOTES > types which I should be adhering to? Is 7 OK? Or what would be a better > number?
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/
| |