[PATCH v2 2/3] Linux: Add the sched_setattr and sched_getattr functions

[Adhemerval Zanella Netto]

On 10/09/24 13:01, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 05/09/24 17:24, Florian Weimer wrote:
>>> And struct sched_attr.
>>>
>>> In sysdeps/unix/sysv/linux/bits/sched.h, the hack that defines
>>> sched_param around the inclusion of <linux/sched/types.h> is quite
>>> ugly, but the definition of struct sched_param has already been
>>> dropped by the kernel, so there is nothing else we can do and maintain
>>> compatibility of <sched.h> with a wide range of kernel header
>>> versions.  (An alternative would involve introducing a separate header
>>> for this functionality, but this seems unnecessary.)
>>>
>>> The existing sched_* functions that change scheduler parameters
>>> are already incompatible with PTHREAD_PRIO_PROTECT mutexes, so
>>> there is no harm in adding more functionality in this area.
>>>
>>> The documentation mostly defers to the Linux manual pages.
>>
>> So I take that the defined approach for syscalls that accepts extensible
>> struct arguments would just to document that it can not be used on places
>> that might affect the ABI, include the kernel definitions if present,
>> and just pass the size to the kernel then?
>>
>> I was not sure how to proceed with the openat2 support back when I first
>> proposed [1] because I felt to me that we did not fully agreed how to
>> handle this cases.
>>
>> [1] https://sourceware.org/pipermail/libc-alpha/2024-April/156319.html
> 
> Adhemerval, according to the minutes (sorry, had to drop), you said
> during the Monday call that you don't want to block inclusion of these
> changes.
> 
> Given that I have a review from Carlos, is it okay now to push these
> changes?  I'm still working on documentation of how extensible types are
> used within glibc and should have something to post later this week
> (hopefully).

Yes. 

Would be too much to add a developer entry, either in wiki or in manual, on 
how to handle the Linux syscall wrappers? Carlos said he intend to write 
down some notes about it, so maybe we can start from there.

I just want to have all the pro and cons of each approach and how glibc
is expected to future Linux syscall wrappers.