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

[Florian Weimer]

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

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,
Florian