This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Principles for syscall wrappers, again


On Tue, May 26, 2015 at 10:55:25AM +0200, Torvald Riegel wrote:
> On Mon, 2015-05-18 at 20:09 -0400, Rich Felker wrote:
> > I would like to see futex in its own header, sys/futex.h, since it has
> > a number of macros. I also tend to think the function itself should be
> > variadic since a few of the argument slots have different types
> > depending on the command in use.
> 
> Roland has argued that we should be adding GNU API extensions, not just
> Linuxisms.  I think futex is a good example of that: I'd prefer us to
> expose functionality that is trimmed down to what's currently widely
> used (e.g., futex_wake(), futex_wait(), ... vs. a single variadic-arg
> futex()).  That makes it easier for things like the Native Client to
> support it, and we can expose a refined interface to users (the futex
> syscalls has seen quite a few changes over time and not all of the
> initial functionality proved to be really useful).
> 
> Thus, it seems to me we should explicitly discuss the GNU API we want to
> expose for each syscall's functionality that we want to offer, and not
> just expose syscalls interfaces as-is by default.

I think this is gratuitous NIH'ing and a disservice to applications.
Code which wants to use the futex API is already doing so via
syscall() with the existing API, and is most easily updated to use
futex(). Your proposed API is not any more general or easier to
provide on NaCl or elsewhere; the existing API can easily be provided
because it's equivalent.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]