This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Principles for syscall wrappers, again


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]