Date: Thu, 06 Sep 2012 13:47:27 +0200 From: Igmar Palsenberg <igmar@...senberg.com> To: musl@...ts.openwall.com Subject: Re: capset() capget() syscalls >> It is an unclear situation. Glibc seems inconsistent. >> >> Personally I think Musl should provide the kernel structures and >> syscalls for everything that is not deprecated. > In principle, I agree with you. > > My impression was that the kernel developers intend for this API to be > deprecated for use by applications, and the only reason they haven't > replaced it with a proper kernelspace API is that they assume you'll > be using libcap which wraps/hides the ugliness (and replaces it with > something else that's just ugly in different ways...). > > As such, it's sort of a borderline case. Do we really want to be > promoting this API for use by applications? I haven't seen a discussion on the capset() capget() API in ages in lkml. My guess : It won't change any time soon. It's use is very specific, so that narrows the change that it will change. About the issue if we want to promote this : Yes, when it comes to capabilities. Most apps don't need full access, but only a subset of it (who wants to unload kernel modules from an application ?). I'm a capabilities fan, not a fan of the API. >> I agree with Linus, provide all the headers in libc. I tried to write >> some code to include all syscalls and constants needed for them, and >> as far as I can see it is impossible with glibc due to conflicts. If >> anyone has a set of includes that works let me know.... > Can you explain what you mean here? Linus' opinion is that including kernel headers in userspace code is the road to destruction of this world. Or something close ;) Igmar
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.