Messages in this thread | | | Date | Wed, 05 May 1999 08:11:32 -0700 (PDT) | From | Jeremy Fitzhardinge <> | Subject | Re: Capabilities: ALPHA time |
| |
On 05-May-99 Pavel Machek wrote: > You did not like that approach and > advocated NOTES. Your arguments was, that if going through multiple > notes shows to be a problem, we can always put capability note at the > beggining. > > Now I've asked you to put capability note at the beggining (well, it > was not for performance reasons but for complication-of-code reasons), > and you showed my why that is bad idea.
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/
| |