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, May 29, 2015 at 10:37:33AM +0200, Torvald Riegel wrote:
> On Thu, 2015-05-28 at 16:51 +0000, Joseph Myers wrote:
> > On Tue, 26 May 2015, Rich Felker wrote:
> > 
> > > > Thus, it seems to me we should explicitly discuss the GNU API we want to
> > > > expose for each syscall's functionality that we want to offer, and not
> > > > just expose syscalls interfaces as-is by default.
> > > 
> > > I think this is gratuitous NIH'ing and a disservice to applications.
> > > Code which wants to use the futex API is already doing so via
> > > syscall() with the existing API, and is most easily updated to use
> > > futex(). Your proposed API is not any more general or easier to
> > > provide on NaCl or elsewhere; the existing API can easily be provided
> > > because it's equivalent.
> > 
> > Agreed.  As I said in 
> > <https://sourceware.org/ml/libc-alpha/2015-05/msg00764.html>, I think the 
> > API details to discuss are things such as the userspace types and the 
> > header with the declaration, not any more substantial rearrangement of the 
> > API - treating Linux as an API source like BSD and SysV, except for API 
> > details outside the scope of what the kernel defines.
> 
> Joseph, the fact that you comment on futex specifically tells me you're
> okay with discussing futex in detail in this thread (which I tried to
> avoid so far).
> 
> I suppose both you and Rich are thinking about this as the futex() API
> you want to expose:
> 
> int futex(int *uaddr, int op, int val, const struct timespec *timeout,
>                  int *uaddr2, int val3);

I would make it variadic with all but the first 3 optional; the types
for the rest are not consistent across commands.

> syscall() is multiplexing.  And so is futex().  Thus, by your logic,
> there's no need for offering futex() because syscall() is doing it
> already, just with *one part* of the multiplexing being variable.

No, the need to add futex is because it should be a cancellation
point, and syscall is not a cancellation point. If you want to write
custom sync primitives that interact with cancellation, futex must be
a cancellation point.

I'm not going to reply to the rest line-by-line, but I don't see how
futex() command multiplexing is any worse than fcntl(). Yes I agree
that, if this were being done fresh from day 1, a non-multiplexed API
is cleaner. That's not what my argument is about. What I believe here
is that:

1. As long as it doesn't have fundamental flaws(*), adopting an API
   with existing usage is better than trying to invent a new one to do
   the same thing.

2. There's a nontrivial risk of omitting access to some features in
   the proposed new non-multiplexed API, and then there's no way to
   get access to a cancellation-point futex command that has those
   features.

(*) By "fundamental flaws", I mean things that make the API unusable
for some purposes and that can't be worked around by wrapping, like
lack of thread-safety. If the existing API can be used to implement
your new API as wrappers, then the existing API does not have the kind
of "fundamental flaws" I'm talking about.

Rich


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