> > Well, I'm still not sure your patch is better. I've seen it and it is
> > much more complicated. _If_ we want to support multiple different CAPS
> > notes with different versions simultaneously, _then_ your patch is the
> > way to go.I'm just not sure having multiple CAPS notes is good idea:
> > it makes kernel code more complicated, it is hard to imagine interface
> > to manipulate such multiple capabilities, and I do not think it is
> > neccessary at all. [You want single capabilities per executable, not
> > arbitrary number of capabilities. The later is too hard to use for
> > use and unneccessary, IMO.]
>
> You miss my point.
>
> Notes are a generic mechanism, and there could be notes in an executable for
> reasons other than capabilties. You can't rely on the CAPS note being first
> because something might put another note before it. Those other notes may be
> something associated with CAPS, like a digital signature. Your technique would
> immediately break as soon as someone tries to do something else with
> ELF notes.
Do you remember our mails from some time before? I advocated using
separate ELF segment with new type. 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.
Well, it probably means (for me) that putting capability info into
NOTE segment is bad idea, and that we should invent our own segment
after all. Are there some real reasons why not invent our own segment?
I feel bad about getting generic note-parsing code into kernel. I
think capability info are quite similar to INTERPRETER segment, and we
should treat them that way. We definitely do not want to go to "what
happens if there are two different capability headers" problem.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- 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/