Re: Specific Linux syscalls for glibc API

[Florian Weimer <fweimer at redhat dot com>]

On 11/18/2015 06:15 PM, Joseph Myers wrote:
> On Wed, 18 Nov 2015, Florian Weimer wrote:
> 
>>> (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.)
>>
>> sched_getcpu is already Linux-specific, no?
> 
> I see nothing Linux-specific in concept about such a call.  I'm not making 
> proposals for which currently Linux-specific interfaces should be part of 
> the OS-independent API, but I suspect plenty should be to be at all 
> consistent with the practice followed by BSD and SVID interfaces.

Ah, okay.

>>>>> * 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.
>>
>> I disagree.  We have to provide interfaces which are reasonably
>> convenient to use.  If we don't do that, programmers will need to write
>> their own wrappers, and everyone loses.
> 
> It's inevitable with new interfaces that people need to deal with them 
> being conditionally supported.  Being easier to use than directly calling 
> "syscall" should be enough for adding an interface, for anything useful to 
> more than just a very few applications.
> 
> A fallback that uses /dev/urandom and /dev/random is probably desirable, 
> especially if a getentropy wrapper is provided, but there's no need for it 
> to be a cannot-fail fallback.  Applications will already handle failure in 
> existing code using /dev/urandom.

I'm still not convinced, but the discussion is rather pointless until
there is a patch.

>>>>> * 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.
>>
>> Apparently, it's mostly related to overlayfs, which is why I'm wondering
>> if it's all that relevant beyond Linux.
> 
> I don't see RENAME_EXCHANGE and RENAME_NOREPLACE as having anything 
> specific to a particular filesystem.  RENAME_WHITEOUT came later.

The atomic aspect of RENAME_EXCHANGE is difficult to implement and
assumes certain file system implementation techniques.

But I was wrong, there is considerable interest in using the call in
coreutils, and Cygwin might implement renameat2, too.

> I think, however, this discussion illustrates a major problem with the 
> libinux-syscalls.so.1 idea: if there is no clear technical way to tell 
> whether a particular interface belongs in that library, then you can get 
> cases of interfaces that appear Linux-specific at first and then are 
> adopted by another system and join the OS-independent API later, meaning 
> either different systems have them in different libraries or glibc for 
> GNU/Linux ends up having copies in both libraries when the interface moves 
> to libc.

Indeed, very good point.

Florian