Re: Principles for syscall wrappers, again

[Joseph Myers <joseph at codesourcery dot com>]

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

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

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

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

-- 
Joseph S. Myers
joseph@codesourcery.com