This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add futex wrapper to glibc?
- From: Darren Hart <dvhart at infradead dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>, 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>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Date: Wed, 29 Oct 2014 19:07:02 -0700
- 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, Oct 26, 2014 at 03:19:22AM -0400, Mike Frysinger wrote:
> On 23 Oct 2014 21:06, Joseph S. Myers wrote:
> > On Thu, 23 Oct 2014, Carlos O'Donell wrote:
> > > The largest problem right now is lack of documentation and that becomes
> > > lack of commitment from the kernel to maintain the API/ABI, and that
> > > translates into reluctance for glibc to create a wrapper.
> >
> > That's not a plausible reason. The presumption is that if any interface
> > provided by the kernel could plausibly be used by userspace, it must stay
> > stable.
>
> sure, but Carlos is speaking in this specific case wrt futex, and it def suffers
> from lack of documentation everywhere. which provides quite a good amount of
> wiggle room for the kernel peeps :).
This kernel peep, and I think I can speak for tglx as well, is not looking for
wiggle room here. We've provide Michael Kerrisk with the return values and error
conditions. I for one treat this as binding.
>
> > * 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.
>
> 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.
>
Agreed, and we have at least a couple examples of futex usage outside of glibc.
(futextest - OK, that one's self-serving, librcu, and I've heard of others)
--
Darren Hart
Intel Open Source Technology Center