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

[enh]

On Fri, Sep 6, 2024 at 8:23 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> > On Thu, Sep 5, 2024 at 4:39 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> > On Thu, Sep 5, 2024 at 3:51 PM Carlos O'Donell <carlos@redhat.com> wrote:
> >> >>
> >> >> On 9/5/24 2:33 PM, Florian Weimer wrote:
> >> >> > These are straightforward system call wrappers.  Like the existing
> >> >> > sched_* scheduler policy functions, sched_setattr interacts poorly with
> >> >> > PTHREAD_PRIO_PROTECT mutexes.
> >> >>
> >> >> As noted by Jopseh Myers in 2015, these interfaces should have had wrappers
> >> >> a long time ago following:
> >> >> https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
> >> >>
> >> >> I think these APIs meet the goals outlined there, modulo their poor interaction
> >> >> with the pthread_* APIs, which is something that can be improved over time.
> >> >
> >> > do you trust upstream not to break source compatibility again? there
> >> > have already been two different versions of this struct with the same
> >> > name. or are you just assuming that next time they do it, userspace
> >> > has a struct sched_attr_2?
> >>
> >> The v2 patch has some additional explanation how the extensibility is
> >> expected to work:
> >>
> >>   [PATCH v2 2/3] Linux: Add the sched_setattr and sched_getattr functions
> >>   <https://inbox.sourceware.org/libc-alpha/1f7f9c80017e91f0af99e1bfd9ec1f59c6cc0da7.1725567796.git.fweimer@redhat.com/>
> >>
> >> It's fairly standard as far as such interfaces go, I think.
> >
> > oh, interesting ... do you have example precedent there?
>
> Isn't it widely used in Windows?  See the dwSize member here for a
> random example:
>
> <https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/ns-tlhelp32-processentry32>

neither binary nor source compatibility with Windows comes up much in
my line of work :-)

(though to be fair to them, the few Windows APIs i am aware of _do_
have suffixes like "2" or "Ex" to evolve in a backwards-compatible
way.)

> Aleksa Sarai's recent series provides a convenient reference of similar
> exensible interfaces used in the Linux UAPI:
>
>   [PATCH RFC v2 00/10] extensible syscalls: CHECK_FIELDS to allow for
>   easier feature detection
>   <https://lore.kernel.org/linux-api/20240906-extensible-structs-check_fields-v2-0-0f46d2de9bad@cyphar.com/>
>
> It's also similar to the tag-length-value approach used by inotify, FUSE
> and others.
>
> > (in particular i'm wondering whether i'm just blanking on other places
> > where this has happened in bionic, or whether the most recent examples
> > pre-date Android/only affected architectures Android doesn't support?)
>
> The obvious one is struct statx (missing from Aleksa's series for some
> reason), although currently the padding fields are being used up.  If
> you have your own definition of struct statx, it still needs regular
> maintenance.

statx(2) is too new to have caused me any trouble yet (i've yet to see
a single user), but i think that one's fine because it uses the

  __u64 __spare3[11];

trick instead, so neither binary nor source compatibility issues there.

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.

> With the arrival of __has_include, in glibc, we generally try to get
> these type definitions from kernel headers.
>
> > maybe. i should perhaps have said that i _started_ doing the
> > sched_setattr()/sched_getattr() work in bionic but found that it broke
> > a bunch of stuff. iirc it was specifically the combination of
> > "everyone has had to polyfill this" and "...but there have been two
> > versions" that made it a pain.
>
> Of course things will break because instead of calling their
> syscall-invoking functions my_sched_getaddr or something like that,
> everyone uses the name that libcs will end up using once they add
> support …
>
> Thanks,
> Florian
>