This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Principles for syscall wrappers, again
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, <libc-alpha at sourceware dot org>
- Date: Fri, 29 May 2015 11:19:45 +0000
- 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>
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.
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. Sometimes we might need to change the futex
implementation in libc to adjust cancellation handling for new operations,
but that's no different from the adjustment of open regarding O_TMPFILE
(bug 17523). Providing access to new operations - at the most specific
level at which this can be done, rather than forcing everything through
syscall - is useful even if occasionally they do need libc changes, as
with O_TMPFILE.
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. The fact that, with hindsight, we might not have designed an API
the way it was in fact designed does not mean we should embed that
viewpoint in the choice of APIs provided to users. This is a C library
and in C we should provide a range of interfaces at different levels, some
easier to use and some closer to the underlying OS interfaces.
--
Joseph S. Myers
joseph@codesourcery.com