This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Florian Weimer <fweimer at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>, Rich Felker <dalias at libc dot org>
- Cc: libc-alpha at sourceware dot org, Roland McGrath <roland at hack dot frob dot com>
- Date: Fri, 05 Jun 2015 10:30:05 +0200
- Subject: Re: Principles for syscall wrappers, again
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1505182114090 dot 16300 at digraph dot polyomino dot org dot uk> <20150519000918 dot GB17573 at brightrain dot aerifal dot cx> <1432630525 dot 3077 dot 36 dot camel at triegel dot csb>
On 05/26/2015 10:55 AM, 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).
These non-variadic interfaces can be implemented in C. A direct wrapper
for futex would have to be written in assembler and pass everything
directly to the kernel. But perhaps the system call wrapper generator
could take of it.
A C implementation which tries to reconstruct the argument list would
have to know all the operations/flags, similar separate to separate
functions for each operation. See bug 17523 for an example why this
could turn out to be relevant.
--
Florian Weimer / Red Hat Product Security