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: Pedro Alves <palves at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 14:36:22 +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> <alpine dot DEB dot 2 dot 10 dot 1511181321270 dot 30047 at digraph dot polyomino dot org dot uk>
On 11/18/2015 01:35 PM, Joseph Myers wrote:
>>> > > * 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.
In general, I wonder whether helping the cross-compilation use case (of portable
programs, not of glibc itself) should be considered in determining the guidelines of
what/when to wrap and provide in the glibc API (not getrandom in particular, but
in general). That is, if some entry point is always provided in the glibc API that
may or may not fail with ENOSYS depending on port, then compile/link autoconf-style
checks are no longer sufficient to determine whether a function is available, while
run-time checks obviously don't work when cross compiling.
Is it already the case that functions in the glibc API may be
exported on all ports but then fail with ENOSYS on some?
Thanks,
Pedro Alves