Re: Principles for syscall wrappers, again

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2015-05-29 at 20:16 +0000, Joseph Myers wrote:
> 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.

I can understand that you don't want to stall an existing API for a
significant time to discuss a new API.  But can we at least agree that
we should spend some thought on whether a new improved API provides a
better service to our users before we just rush out just the existing
API?  I'm not asking for bike-shedding but more of sanity check.

> > > 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.

There's still more manual setup required for a syscall than for a normal
C function where almost all of the machinery is handled by the
toolchain.

Also, why would anyone multiplex several logically different operations,
with type-unsafe parameter multiplexing and all that, into a single C
function -- instead of just using several C functions?  I can't think of
any reason but wanting to limit the number of functions/syscalls.

> > 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.

I said "*just* offering futex()", and I meant only futex().  We can
offer both futex() and the proper interface and still support the use
case you mentioned above.

> > 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.

OK.  I notice you said "only providing higher-level" interfaces; so, do
I understand you correctly that you're primary concern here is to
provide futex(), and that you don't necessarily object to a proper
interface, nor think that offering futex() renders offering a proper
interface obsolete?

> 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.

OK.