Re: Specific Linux syscalls for glibc API

[Pedro Alves <palves at redhat dot com>]

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