From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1912 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: capset() capget() syscalls Date: Sun, 9 Sep 2012 17:55:16 -0400 Message-ID: <20120909215516.GJ27715@brightrain.aerifal.cx> References: <20120905061905.GQ27715@brightrain.aerifal.cx> <50471B56.8040804@palsenberg.com> <20120905142441.GT27715@brightrain.aerifal.cx> <20120906030406.GY27715@brightrain.aerifal.cx> <20120907045631.GL27715@brightrain.aerifal.cx> <20120908221449.GZ27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1347227561 23377 80.91.229.3 (9 Sep 2012 21:52:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2012 21:52:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1913-gllmg-musl=m.gmane.org@lists.openwall.com Sun Sep 09 23:52:44 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1TApQo-0007H8-1i for gllmg-musl@plane.gmane.org; Sun, 09 Sep 2012 23:52:42 +0200 Original-Received: (qmail 5458 invoked by uid 550); 9 Sep 2012 21:52:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5450 invoked from network); 9 Sep 2012 21:52:38 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1912 Archived-At: On Sun, Sep 09, 2012 at 05:13:55PM -0400, James Cloos wrote: > >>>>> "RF" == Rich Felker writes: > > >> futex > > RF> glibc does not expose this as far as I know. I would not be opposed > RF> to having sys/futex.h however. It's less ugly than having to use > RF> linux/futex.h and syscall()... > > +1. and a separate library seems to be the best way to > support the futex interface. Such a lib might try to be portable with > support for other lock and semaphore apis when futex(7)s are unavailable. With something like futex that's a trivial syscall, I'm not sure what qualifies it for a separate lib rather than inclusion in libc. The library would be <20 bytes of code on most archs... That's not to say I think we have to expose it in musl, but I think using a separate library (especially if there's any chance of it being built as a .so rather than just .a) is a worse choice than just writing syscall(SYS_futex, ...) in your source... Rich