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

[Adhemerval Zanella Netto]

On 06/09/24 10:26, 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
> 
> See the parallel discussion with enh.  I don't think it's a big problem.
> 
> We already have struct statx in the installed headers, which behaves
> pretty much the same way, except that extensions are currently using up
> the padding space.

The statx is slight different wrt to kABI because it does not really
follow the current behavior or adding the size for the syscall (and
I recall some kernel developers to regret this decision).

I still unsure this is really a good way forward, since it does have some
drawbacks about possible misuse.  This would be first symbol that follow
this new semantic, so I think we should document this properly either
on the wiki that Linux syscall might folow this strategies and how the
wrapper should be added.