This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Fri, 29 May 2015 10:07:06 -0400
- 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> <20150526151000 dot GA17573 at brightrain dot aerifal dot cx> <alpine dot DEB dot 2 dot 10 dot 1505281648440 dot 16930 at digraph dot polyomino dot org dot uk> <1432888653 dot 30849 dot 146 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1505291103540 dot 2439 at digraph dot polyomino dot org dot uk> <1432900697 dot 30849 dot 178 dot camel at triegel dot csb>
On Fri, May 29, 2015 at 01:58:17PM +0200, Torvald Riegel wrote:
> On Fri, 2015-05-29 at 11:19 +0000, Joseph Myers wrote:
> > On Fri, 29 May 2015, Torvald Riegel wrote:
> >
> > > syscall() is multiplexing. And so is futex(). Thus, by your logic,
> > > there's no need for offering futex() because syscall() is doing it
> > > already, just with *one part* of the multiplexing being variable.
> >
> > The syscall function doesn't deal with cancellation.
>
> Agreed. But not all futex operations are cancellation points either.
>
> And what if we had syscall() and a variant of that that supports
> cancellation? Then the cancellation argument you make is taken care of,
> or am I missing something?
I think that would solve the technical problem, yes.
> > My proposed principles are non-exclusive. I consider the futex call to be
> > useful in the same way as open or ptrace or ioctl - a function providing
> > access to a range of related operations, some system-independent and some
> > with system-specific aspects. This does not exclude the possibility of
> > other APIs being useful for particular cases of the futex call, or indeed
> > of applying my proposed principles recursively to cases of particular
> > multiplexing system calls.
> >
> > A futex function is useful to provide access to new futex operations
> > without needing libc changes for them, much like open and ptrace provide
> > access to new operations.
>
> I would not be opposed to *additionally* offering a futex() operation
> that can be used as a fallback should we ever get new futex operations.
> However, the existence of an exposed futex() fallback should never be a
> reason to not provide a proper futex interface.
I would fully support having both a full-featured futex() multiplexing
function and individual clean-API wrappers for common operations. I
would even be fine with only the latter being part of the
"cross-platform GNU API" and the former being Linux-only, though of
course I would prefer both be treated as first-class APIs.
> > I think it would have been harmful to users to insist that all unknown
> > ioctl uses go through the syscall function unless we've individually
> > reviewed and second-guessed the interface in every case - it would just
> > gratuitously complicate their code. And I think the same applies to
> > futex.
>
> That may be a proper analogy if we'd be looking at adding a futex API
> while the kernel-level set of futex operations still evolved. But right
> now, we're looking at a pretty stable set of operations, and we have
> documentation from the kernel that actually describes the intended
> logical API (which is then transformed into the multiplexing scheme
> used).
Look at it this way: if the kernel adds a new futex command, how long
will it take to get glibc support for it with multiplexer vs
individual functions? And to get that support deployed into mainstream
distros? :-)
Rich