Re: Specific Linux syscalls for glibc API

[Florian Weimer <fweimer at redhat dot com>]

On 11/18/2015 02:35 PM, Joseph Myers wrote:
> On Wed, 18 Nov 2015, Florian Weimer wrote:
> 
>> On 11/17/2015 05:34 PM, Joseph Myers wrote:
>>
>>> Old functions (where any relevant syscalls have been in the kernel since 
>>> 3.2 or earlier, when routine addition of syscall wrappers to glibc 
>>> stopped):
>>>
>>> * gettid, pthread_gettid_np (bug 6399).
>>
>> I have no problem with adding those for Linux only.  I have some
>> concerns about exposing them as a general (OS-independent) interface
>> because they NPTL deals with TIDs appears quite broken.  On the other
>> hand, it looks like a better implementation would support all uses cases
>> currently supported by NPTL in a race-free manner, and some other useful
>> scenarios as well.
> 
> Do you then think that the TID concept is unique to Linux - that it 
> doesn't exist for any other NPTL ports, such as that for NaCl or the 
> variant used in the out-of-tree kFreeBSD port of glibc, or on other OSes?

The shared TID/PID namespace seems very Linux-specific.  FreeBSD has
TIDs, but as far as I can tell, they are restricted to the calling
process, and do not extend to the entire namespace.

TIDs might also be pointers on some systems, while PIDs are ints.  There
could also be conflicts between PIDs and TIDs (there could be PID 1 and
a TID 1, and both are not the same).

> (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?

>>> * 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.

>>> * 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.

> My concept of OS-independent APIs is intended to be such that the older 
> BSD and SVID APIs are not considered OS-specific simply if in fact they 
> were only natively implemented for particular BSD or SysV systems, but the 
> concept of the API is meaningful for other OSes and it's plausible at 
> least some features could be supported on other OSes if someone so 
> desires.

And that's actually quite difficult with renameat2, it does leak file
system implementation details (as does posix_fallocate).

>>> * sched_setattr.
>>>
>>> * sched_getattr.
>>
>> I think we need to discuss to what extent emulation is possible, but
> 
> I don't think that's a necessary part of adding a syscall wrapper.  If an 
> interface is OK, it should always be OK to add a wrapper that doesn't try 
> emulation on older kernels, with emulation being an incremental 
> improvement if someone is interested in it.

Okay, I can see your point for such APIs.

>> otherwise, these seem reasonable to add, but they are Linux-specific,
>> not for the general OS-independent API.
> 
> Under my model of what counts as OS-independent (with, as noted, the 
> caveat that we could treat more as Linux-specific if it doesn't mean 
> putting them in a separate library), I don't see these are more 
> Linux-specific than the concept of TIDs.

Look at the struct definition as presented in the manual page:

           struct sched_attr {
               u32 size;              /* Size of this structure */
               u32 sched_policy;      /* Policy (SCHED_*) */
               u64 sched_flags;       /* Flags */
               s32 sched_nice;        /* Nice value (SCHED_OTHER,
                                         SCHED_BATCH) */
               u32 sched_priority;    /* Static priority (SCHED_FIFO,
                                         SCHED_RR) */
               /* Remaining fields are for SCHED_DEADLINE */
               u64 sched_runtime;
               u64 sched_deadline;
               u64 sched_period;
           };

Even discounting the type definitions, these look *very* specific to a
particular scheduler algorithm and its implementation.

Florian