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

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