[PATCH 0/3] Add the sched_setattr, sched_getattr functions

[Carlos O'Donell]

On 9/6/24 1:33 PM, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 06/09/24 11:04, Florian Weimer wrote:
>>>> the struct sched_attr alternative of
>>>>
>>>>   __u32 size;
>>>>
>>>> is fine from a kernel-userspace binary compatibility perspective, but
>>>> doesn't help with userspace-userspace compatibility (like the
>>>> 32-/64-bit time_t discussion), nor source compatibility.
>>>
>>> That's fair, it's not something that you are expected to use in a public
>>> header, and my manual update try this to explain that.  And it's similar
>>> to struct dirent that copying values requires a bit of fiddling (the
>>> kernel may produce names that overflow the embedded string space in
>>> struct dirent).
>>>
>>
>>> There isn't any thing special to the initial addition, as long as we
>>> don't do emulation.  Strucurally, sched_getattr has the same behavior as
>>> recv, for example.  It makes sense to put something into the manual
>>> about extending the struct, and I did that.
>>
>> That's is the same issues that I discussed with Elliot on the openat2
>> and that we did not come up with defined strategy because each direction
>> would require some tradeoffs:
>>
>>   1. Follow kABI and tie the struct with a size:
>>      PRO: it simplifies implementation and allows any possible kernel
>>           extension.
>>      CON: it adds possible subtle bugs in userspace binary compatibility,
>>           and also does not have fully source compatibility (the source
>>           relies on the installed kernel headers).
>>
>>   2. Add a libc defined struct, possible with slack space for extension:
>>      PRO: Binary and source compatibility across glibc and kernel releases.
>>      CON: It would require to sync any extra flags for current supported
>>           fieds, and any extra field that do not fit in the slack space
>>           would require a new symbol version.
> 
> CON for 2 is also that it's pretty close to emulation, which we know
> doesn't work.  We have to check all flags and fail all unknown things
> proactively because we can't be sure how unknown flags interact with the
> official kernel-supported extension mechanism.  This means that any new
> functionality will require kernel and glibc updates.  I expect
> applications not to adopt this, sticking to direct system calls and the
> UAPI headers instead.

Agreed.

The required double update is very high friction for downstream distributions.

Impossible really if a new symbol set is required because you need more bytes.

I also think that if we want to add an *additional* symbol for #2, then we can do
that, but collaboration with musl and bionic on libc-coord would be a good idea.

> I also expect that the run-time checks for 1 are easier to write than
> the compile-time checks for 2, even if we provide suitable preprocessor
> macros to enable conditional compilation based on the availability of
> different struct versions.
> 
>> I have a slight inclination to *not* follow kernel way, since it was not
>> designed for userland possible issues and the subtle problems are really
>> difficult to debug.
> 
> I disagree, it works just fine for userspace.  You just need follow the
> same extension protocol for the relevant interface.
> 
> Anyway, I'm not going to push the sched_attr changes for now, and will
> work on a new section for the manual on types which change their layout.

Thanks.

-- 
Cheers,
Carlos.