No, I suggested putting the CAPS note as the first as a performance hack. The
code should still be able to cope with other arrangements. After all, until
someone does start using notes for something else, there will only be the CAPS
note. You just have to be flexible in dealing with whatever you find.
> Are there some real reasons why not invent our own segment?
Yes:
- putting caps in notes is a short-term hack to work around the lack of support
in the filesystem. It also has a secondary role of allowing caps to be
transported with the executable between filesystems.
- ELF files are well defined and can be modified by anything which understands
ELF files. What you're proposing would mean Linux executables are no longer
ELF files, and can no longer be processed by other tools. I regularly use
Solaris tools on Linux ELF files. Numerous other operating systems can
directly execute Linux ELF binaries, which would break if you start introducing
new ELF segments.
- to amplify: redefining a file format is a Big Change, because once you've
defined it you're stuck with it *forever*. It is not something you do lightly,
and it's certainly not something you do on the spur of the moment while hacking
up a prototype to avoid a few lines of code. As it is you have to define the
shape of the capabilities note, but at least that's well encapsulated within
the notes mechanism.
The basic point is that capabilities are just not that important in the scheme
of things. Sure, they very useful and have some great properties, but that's
not enough to make large-scale incompatible changes for no good reason.
I'm advocating a light touch - only do what's necessary to get the job done and
no more. For the sake of a few lines of code in binfmt_exec.c, you're
proposing redefining ELF and breaking compatibility with no clear gain.
> I feel bad about getting generic note-parsing code into kernel.
Why? What are you worried about? Complexity? Performance?
You can't argue about performance without having done any measurements. And
once there's measurements there's a solid basis for improving performance.
Premature optimisation is never useful, particularly when it leads to an uglier
design.
The note-parsing code is trivial. It's one function which adds no conceptual
complexity to the capabilities code path. The pay-off for those few lines of
code is that capabilities make use of the generic mechanisms of ELF in the way
they were designed to be used, and the code is more robust in the face of
future changes.
> I think capability info are quite similar to INTERPRETER segment, and we
> should treat them that way.
Interpreter segments are already well-defined in ELF, and are generally useful
to lots of applications and operating systems.
> We definitely do not want to go to "what
> happens if there are two different capability headers" problem.
There's three ways of dealing with that:
a. reject the executable
b. use the first
c. find the least capable union
The code currently does b.
-
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/