Re: Principles for syscall wrappers, again

[Torvald Riegel <triegel at redhat dot com>]

On Fri, 2015-05-29 at 15:34 +0000, Joseph Myers wrote:
> On Fri, 29 May 2015, Torvald Riegel wrote:
> 
> > > > And I still don't really see the harm for users.  Can you be more
> > > > specific?  Are you concerned about availability, or timely availability,
> > > > or deviation to the lowest-level OS interface, or usability, or ...?
> > > 
> > > All of these.
> > 
> > Really?  Usability includes ease-of-use to me, and having to put an int
> > into a timespec* parameter that has a completely unintuitive name for
> > that use really does conflict with ease-of-use to me.  Why do you think
> > that's not the case?
> 
> Usability includes being able to follow the existing documented interface 
> rather than "the glibc people decided that was NIH, so you need to apply 
> these transformations and hope your use case was one they thought 
> relevant".

You can certainly disagree that an improvement I claim is not actually
an improvement, but characterizing it as NIH is inappropriate IMO.  NIH
tries to sum up a person's or group's mindset or objectives, so I'd like
to ask you to stop trying to speculate about my intentions.  If you
disagree on the claimed improvement, do that instead.

> > > I think glibc will be more useful in practice if we are 
> > > more willing to delegate certain areas of low-level API design and 
> > > implement APIs designed in the Linux kernel community like we do with 
> > > POSIX APIs.
> > 
> > I doubt the POSIX API and the Linux syscall APIs have the same target
> > users.  If we had a futex API that would be at a level similar to POSIX,
> 
> They don't (POSIX provides the pthreads interfaces for synchronization), 
> but libc caters to a range of different target users.

I was arguing that your analogy doesn't hold.

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

> > In the general case, I just want us to (1) consider whether, for a
> > particular syscall, we are in a similar situation as for futexes; (2)
> 
> 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.

Thus, what can be right for a kernel interface can differ from a
function-based interface, right?  Remember that we're not even
discussing a difference in functionality here, just basics like no
unnecessary multiplexing, no type-unsafe reuse of parameters, and
actually using parameter names that are meaningful.

>From the kernel's perspective, there's no reason to change the futex API
now because they won't change an interface anyway unless it's obviously
dysfunctional.  But that's simply not the question nor the constraint
set that we face.  We have to provide something useful to our users, not
blindly copy design decisions made for a different situations (ie, for a
kernel interface, not for a glibc / GNU / ... interface).  Note that I'm
not saying the kernel's choice is bad, it's just in a different context.

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?

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?

> > discuss the situation and see whether there is consensus on offering an
> > API that is more useful to the majority of glibc users or GNU system
> > developers; and (3) try to provide such an API in the same release in
> > which we might provide a lowest-level API as well.
> > 
> > (I'm adding (3) because I don't want us to provide futex() suport in
> > release N, followed by users creating their own wrappers for it if they
> > want cleaner interfaces -- and then we provide a proper interface in
> > release N+1 and everyone has to change again or live with their own
> > variants.)
> 
> But actually we're closer to the situation of having provided the 
> low-level syscall() interface to futex in release N with any better 
> interface being derailed and delayed to N+20.

How long we had syscall is irrelevant here, strictly speaking.  You seem
to worry about some improvement over syscall taking more time -- but the
reason for this could only mean that we two disagree whether we should
have both futex() and proper or just futex().  Based on that, it's not
clear who is actually preventing consensus here.