From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1916 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 18:29:17 -0400 Message-ID: <20120909222917.GL27715@brightrain.aerifal.cx> References: <20120905142441.GT27715@brightrain.aerifal.cx> <20120906030406.GY27715@brightrain.aerifal.cx> <20120907045631.GL27715@brightrain.aerifal.cx> <20120908221449.GZ27715@brightrain.aerifal.cx> <20120909215516.GJ27715@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 1347229602 4452 80.91.229.3 (9 Sep 2012 22:26:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Sep 2012 22:26:42 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1917-gllmg-musl=m.gmane.org@lists.openwall.com Mon Sep 10 00:26:42 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 1TApxi-0004HA-C7 for gllmg-musl@plane.gmane.org; Mon, 10 Sep 2012 00:26:42 +0200 Original-Received: (qmail 15365 invoked by uid 550); 9 Sep 2012 22:26: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 14333 invoked from network); 9 Sep 2012 22:26: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:1916 Archived-At: On Sun, Sep 09, 2012 at 11:12:01PM +0100, Justin Cormack wrote: > On Sun, Sep 9, 2012 at 10:55 PM, Rich Felker wrote: > > 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... > > The manpage says > > To reiterate, bare futexes are not intended as an easy-to-use > abstraction for end-users. (There > is no wrapper function for this system call in glibc.) > Implementors are expected to be assembly > literate and to have read the sources of the futex userspace > library referenced below. > > I thought (from memory) the non-contended case required architecture > specific assembly, the syscall just dealt with contended case. So the > library needs to provide the other stuff to make it usable. Its not a > lot, and must be there to use these for threading I guess, but doesnt > have standard names? "GNU C" (GCC-specific) or C11 atomics will work perfectly well in place of assembly; the whole point of exposing the futex syscall to the application would be for it to do its own waiting in conjunction with atomics (whether implemented with GNUC, C11, or asm). The futex API is mainly for waiting on locks or waking waiters; for the most part it does not even provide an API for obtaining locks, although the prio-inheritance stuff can provide full locking in kernelspace, albeit very inefficiently. We're talking 200x slower than calling pthread_mutex_lock, so it would be utterly useless.. Rich