* Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > Quoting Chris Wright ([EMAIL PROTECTED]): > > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > > I guess now that I've written this out, it seems pretty clear > > > that capget64() and capget64() are the way to go. Any objections? > > > > How is capget64() different from capget() that supports 2 different > > header->versions (I thought that was the whole point of the versioned, > > rather opaque interface)? I don't object to a new syscall, but I don't > > see why it's required to avoid breaking libcap. > > Hmm, I guess it *works*, it's just harder to explain the "inconsistent" > behavior. Now instead of saying "capget() will fail under certain > conditions while capget64() will always succeed", capget() will actually > fail under certain conditions only if you send in a certain header. > > Again, once I've written it out, I guess it isn't *so* bad.
It's not really any different than issuing capget(0x19980330) (assuming capget64 is different), and getting -EINVAL when the actual in-use caps are > 32 bits wide. In either case the rules are the same -- old interface works fine as long as you don't have new caps involved. Only advantage I see to using the extant interface is that the cap[sg]et interface is already designed to be future-proof (albeit in an unusual way compared with most other kernel syscalls). thanks, -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
