This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Mike Frysinger <vapier at gentoo dot org>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Rich Felker <dalias at libc dot org>, Roland McGrath <roland at hack dot frob dot com>, Torvald Riegel <triegel at redhat dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Darren Hart <dvhart at infradead dot org>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Mon, 27 Oct 2014 17:52:32 +0000
- Subject: Re: Add futex wrapper to glibc?
- Authentication-results: sourceware.org; auth=none
- References: <1410881785 dot 4967 dot 292 dot camel at triegel dot csb> <20140917194100 dot 23B722C26C5 at topped-with-meat dot com> <1410983178 dot 27838 dot 27 dot camel at triegel dot csb> <20140917195918 dot 6F06C2C3974 at topped-with-meat dot com> <20140917231708 dot GC23797 at brightrain dot aerifal dot cx> <544953F7 dot 1020607 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1410232050160 dot 19073 at digraph dot polyomino dot org dot uk> <20141026071922 dot GA21885 at vapier>
On Sun, 26 Oct 2014, Mike Frysinger wrote:
> > * Otherwise, my inclination would be to default to adding wrappers (both
> > for syscalls not used in glibc, and for cases such as futex where the
> > syscall is used in glibc but can usefully be used directly as well) unless
> > there is a clear reason not to. This includes for architecture-specific
> > syscalls.
>
> i disagree here. if the func is not going to be generally useful, i
> don't think glibc should pick it up. especially for arch-specific
> syscalls. i think the kernel itself is much better suited for providing
> a thin wrapper layer for userspace as they're directly in control of the
> ABI (especially cross-arch) and the API (via the UAPI headers), they can
> provide a full API for all syscalls (unlike glibc per the caveats listed
> above), and it means there's a central source point for everyone to use,
> not just glibc.
I don't think the kernel is well-suited for this; various issues around
building objects for all the different ABIs, including ABI differences
that are only relevant at the userspace level and not the kernel level,
don't arise for kernel code (and only to a limited extent for vDSOs) - and
then you get into things such as providing unwind / debug info for syscall
stubs. If the syscall is to be a cancellation point (and it was suggested
the futex wrapper should be, for certain arguments) then the syscall
implementation closely ties into libc internals (and if it sets errno,
that means the object code for the implementation depends on libc, even if
it would be possible to write C source code for it that does not).
> if the syscall is generally useful to people writing userland code, then
> i don't see a problem with incorporating it in some fashion into the
> official GNU API.
Sometimes "access this Linux kernel interface" is generally useful (e.g.
gettid, futex - and plenty of existing syscall wrappers).
> i think any syscall we think about adopting, this should be given
> serious consideration. ideally glibc's API should be stable across
> platforms. if the Linux syscall is so great as to warrant us adding a
> wrapper, then it stands to reason that equivalent functionality should
> be desirable on other platforms. it doesn't mean we need to wait for
> them to implement the kernel side, but we shouldn't be baking in pure
> Linuxisms from the start. -mike
I don't think we actually need to decide at the time of adding a syscall
wrapper whether it would be useful on other platforms - if we decide that
later, we can always add the ENOSYS stub for Hurd use, or fallbacks for
older Linux kernel versions, at that point. (If we wish to use a function
internally in glibc in OS-independent code, that would be a good
indication that it should be made an OS-independent interface.)
Nor do I think we can reliably predict whether an interface is suitable to
be OS-independent from whether it is generally useful with the Linux
kernel - it may be necessary to see how several different OSes approach an
issue before a good conclusion can be reached on what a portable
OS-independent interface should look like.
--
Joseph S. Myers
joseph@codesourcery.com