Re: Implementation of sys/capabilities.h

[Igmar Palsenberg <musl@palsenberg.com>]

> On Mon, Aug 27, 2012 at 11:23 AM, Igmar Palsenberg <igmar@palsenberg.com> wrote:
>>> Why in Musl out of interest? They are not in other libc's, and people
>>> expect to link to libcap for them surely. And some people argue that
>>> the interfaces are not very well designed (indeed libcap seems to be
>>> adding extra ones not in the withdrawn posix draft), eg see
>>> http://people.redhat.com/sgrubb/libcap-ng/
>> 
>> It's open for debate. The syscalls need to be there (including the structs the kernel uses), and I've got those in a patch.
>> 
>> I agree the interface is shit : Way to complicated, while only need some simple functions, with a bitmap to represent them. Why implement it ?
>> It's the only thing we got, and programs assume it's POSIX, so it should be present. Yes, it's broken, but capabilities are a needed feature if you ask me.
>> 
> 
> Definitely add the syscalls, anyway, regardless.

I'll submit a patch for that. Rich, can you handle pull request, or you want the patch on the ML ?

> I am just not sure that "programs assume it's POSIX, so it should be
> present", I would assume they would expect to have to link against
> external libcap, which would be an explicit dependency, not assumed
> part of libc. They are part of the draft POSIX 1e, but it is only a
> suggestion and not a standard, and really needed more work.
> 
> It is a difficult one, as the kernel API is a bit unpleasant. But
> including a partial implementation is asking for trouble too. Perhaps
> another option is a posix 1e companion library that implements the
> other parts? Not sure...

I prefer the kernel API over libcap any time. Kernel is one header struct (2 fields), and a struct with 3 bitfields. Can't get any easier if you ask me.
I'll submit a patch for the kernel ABI, the rest if I look at it again, doesn't belong in musl.



	Igmar