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: Specific Linux syscalls for glibc API


On 11/17/2015 05:34 PM, Joseph Myers wrote:

> Old functions (where any relevant syscalls have been in the kernel since 
> 3.2 or earlier, when routine addition of syscall wrappers to glibc 
> stopped):
> 
> * gettid, pthread_gettid_np (bug 6399).

I have no problem with adding those for Linux only.  I have some
concerns about exposing them as a general (OS-independent) interface
because they NPTL deals with TIDs appears quite broken.  On the other
hand, it looks like a better implementation would support all uses cases
currently supported by NPTL in a race-free manner, and some other useful
scenarios as well.

(My concern is that TIDs are invalidated before pthread_join is called.)

> * futex and more specific futex_* interfaces for individual operations 
> (bug 9712).

I think we should treat futex like socketcall and not wrap it.  We
discussed this in the context of the the open wrapper, and it turned out
impossible to intercept and forward such a vararg call properly in C
code.  Exposing individual futex operations as functions is a good idea.

> New functions (post-3.2 additions to the kernel):
> 
> * getrandom, plus BSD getentropy wrapper (bug 17252).

A high-quality implementation of getrandom is difficult because the most
interesting property of getrandom is that it cannot fail in some modes
of operation.  A wrapper would have to provide reliable emulation,
otherwise application code would need to check for ENOSYS, entirely
defeating the purpose of this interface.

> * renameat2 (bug 17662).

I'm okay with that as long as we do not try to provide emulation (so,
return ENOSYS on an older kernel and EINVAL without file system
support).  This system call is rather Linux-specific, though.

> * sched_setattr.
> 
> * sched_getattr.

I think we need to discuss to what extent emulation is possible, but
otherwise, these seem reasonable to add, but they are Linux-specific,
not for the general OS-independent API.

> * memfd_create.

That one essentially brings in the entire sealing API (F_SEAL_*
interface for fcntl).  I still don't understand the purpose (it would
have vastly more useful to have safe access to mappings instead of
sealing), but now that it's there, we can support it (without emulation).

> * execveat.

Reasonable to add.  Can be emulated faithfully with /proc/self/fd and
O_PATH.  Not sure if this is for the OS-independent API, but the other
*at are OS-independent, so it makes sense to put it there as well.

> * membarrier.
> 
> * mlock2 (new for 4.4).

Have not seen those yet.

Florian


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