This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Specific Linux syscalls for glibc API
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Wed, 18 Nov 2015 13:35:10 +0000
- Subject: Re: Specific Linux syscalls for glibc API
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511171606330 dot 14808 at digraph dot polyomino dot org dot uk> <564C4DCA dot 3010607 at redhat dot com>
On Wed, 18 Nov 2015, Florian Weimer wrote:
> 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.
Do you then think that the TID concept is unique to Linux - that it
doesn't exist for any other NPTL ports, such as that for NaCl or the
variant used in the out-of-tree kFreeBSD port of glibc, or on other OSes?
(If we drop the libinux-syscalls.so.1 idea and accept Linux-specific
interfaces in libc.so.N, I don't object to erring on the side of treating
more interfaces as Linux-specific in the first instance with generic stubs
potentially being added later.)
> > * 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,
That's not our problem to solve. The manpage explicitly says that the
return value must be checked. We should provide a wrapper, not
necessarily with any emulation, and if there's emulation, it might fail.
At some future point glibc will require a kernel version recent enough to
have the syscall, at which point applications using new enough glibc may
know, on Linux but not necessarily on other OSes, that it cannot fail. We
should not delay adding a wrapper until we can rely on the syscall being
available.
> otherwise application code would need to check for ENOSYS, entirely
> defeating the purpose of this interface.
Applications supporting older kernels need to allow for the syscall /
function not being available anyway. Again, not our problem to solve when
providing a wrapper.
> > * 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.
I don't see it as Linux-specific. That is, it seems to be defined in a
generic way that it's entirely plausible other OSes would be able to
implement, whether in the kernel or (e.g. on Hurd) in userspace to a
greater or lesser extent.
My concept of OS-independent APIs is intended to be such that the older
BSD and SVID APIs are not considered OS-specific simply if in fact they
were only natively implemented for particular BSD or SysV systems, but the
concept of the API is meaningful for other OSes and it's plausible at
least some features could be supported on other OSes if someone so
desires.
> > * sched_setattr.
> >
> > * sched_getattr.
>
> I think we need to discuss to what extent emulation is possible, but
I don't think that's a necessary part of adding a syscall wrapper. If an
interface is OK, it should always be OK to add a wrapper that doesn't try
emulation on older kernels, with emulation being an incremental
improvement if someone is interested in it.
> otherwise, these seem reasonable to add, but they are Linux-specific,
> not for the general OS-independent API.
Under my model of what counts as OS-independent (with, as noted, the
caveat that we could treat more as Linux-specific if it doesn't mean
putting them in a separate library), I don't see these are more
Linux-specific than the concept of TIDs.
> > * 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.
This is the one that's most completely obviously OS-independent even for
a narrow concept of OS-independence. It's also of use for implementing
fexecve when available.
--
Joseph S. Myers
joseph@codesourcery.com