[lkml]   [1999]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:4.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site