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 20:16:02 +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> <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> <alpine dot DEB dot 2 dot 10 dot 1505291301400 dot 18021 at digraph dot polyomino dot org dot uk> <1432908585 dot 30849 dot 213 dot camel at triegel dot csb> <alpine dot DEB dot 2 dot 10 dot 1505291524290 dot 27491 at digraph dot polyomino dot org dot uk> <1432923248 dot 4832 dot 40 dot camel at triegel dot csb>
On Fri, 29 May 2015, Torvald Riegel wrote:
> > > I'm confused. You said you don't see adding futex() as a reason to not
> > > add a proper futex interface, yet here you seem to say that the latter
> > > would be bad for us. Can you clarify?
> >
> > What would be bad is letting discussion of a multiple-function interface
> > obstruct consideration and acceptance of a patch adding the basic
> > interface.
>
> Sure, but we haven't actually found out whether there would be any
> obstruction. Rich says he wouldn't mind having both, others haven't
> commented. What's your thought on having both? Are you opposed to
> having both, or where do you think the obstruction would come from?
I do not object to having both. I do object to a new API being any sort
of prerequisite for adding the known and understood API.
> > Any such consideration should only be in the basis of compelling Linux
> > kernel consensus that the existing API is deficient and a particular
> > alternative API is how it would be designed now, not on the basis of
> > substituting our own opinion for the review that already took place on
> > linux-api when the syscall was added (I think the principles for new
> > syscalls that postdate the present review process on linux-api are more
> > important than the application to older syscalls).
>
> What they exposed has different constraints than what we expose, do you
> agree? For example, number of syscalls may matter to them, number of
> functions we expose doesn't really matter much. Or differences between
> syscalls and function calls.
I don't see any real difference in significance between number of syscalls
and number of functions. A syscall is essentially a function call that
happens to cross a privilege boundary and all new syscalls come with an
intended C API (modulo details of exactly what the libc-level typedefs
are, etc.) - the design considerations are essentially the same.
> I mean, in glibc we already do use a different interface than futex(),
> and always have, right? And IIRC, futexes have been developed at least
> with a lot of input from glibc. Isn't that enough indication that just
> offering futex() wouldn't be what people actually need?
The point of providing the futex interface is to provide for any use
someone comes up with, not just those we envisage or that are useful
directly within glibc.
> Also, in what you wrote above you express your opinion how the rules
> should be -- could you also offer reasoning why this should be the case?
I think that having the kernel interfaces conveniently available to users,
so they can use whatever combinations of userspace and kernel interfaces
seem appropriate without needing to be concerned with the details of which
parts of the functionality are implemented in userspace or with
architecture-specific syscall argument handling, is better for glibc than
only providing higher-level interfaces, or than providing documentation
that presents one particular viewpoint on the deficiencies of an external
standard and declares a feature unsupported (something common in older GNU
documentation), and that the kernel API review process is (now)
sufficiently good that the benefits of compatibility with the kernel and
its documentation outweight any disadvantages of imperfections in the
interfaces.
I apply this principle both ways - I think the kernel should do more to
support POSIX requirements (e.g. set*id for multi-threaded processes)
rather than declaring those requirements, or the parts that are
problematic to implement in userspace, to be uninteresting.
I think that if the manpage for a syscall needs to document the absence of
a corresponding glibc function, that's an embarrassment to glibc - that
we're not keeping up with external changes (Linux is at least as
appropriate an API source now as BSD and SysV were originally) - in the
absence of a clear reason making the syscall inappropriate for glibc.
--
Joseph S. Myers
joseph@codesourcery.com
- References:
- Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again
- Re: Principles for syscall wrappers, again