lkml.org 
[lkml]   [1999]   [May]   [20]   [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 [diff against 2.3.1]]
On Tue, 18 May 1999, Pavel Machek wrote:
> I changed structure fields from Elf32_Word to __u32. Now, structure is
> tied to elf only by its possition <linux/elf.h> and its name
> (elf_capabilities). Possition and name of structure are small details,
> I believe. I do not want to move structure to other file (so my diff
> is small), and I do not know better name (suggest one).
Yes my cap19 uses __u32 as well, the structure is stored in
linux/capability.h with the name kill_capabilities to highlight that they
*kill* capabilities never raise.
maybe a friendlier name would be bin_capabilities_kill also did basicily a
s/ECF/KCF/g maybe I should make it BCKF.
Why should binfmt_aout.c include linux/elf.h if support gets added for
a.out bincap? linux/binfmt.h already includes linux/capability.h .
I still need to make good on my promise and expand the fields from
__u32 foo; to __u32 foo[4] as approriate. Have to change my user level
program and the patch itself. expect linux-cap20 RSN.

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?
> > 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;->

--
Any caps I mention are *derived* from a withdrawn draft posix document.
See http://www.millenniumproductsllc.com/sjp/ for more info.


-
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    [from the cache]
©2003-2011 Jasper Spaans