This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Is adding a pthread wrapper for sched_{get,set}attr feasible?
Hi,
On 22/08/18 23:00, Florian Weimer wrote:
> * Szabolcs Nagy:
>
> > the main ugliness about reusing sched_param is that it's
> > an abi break, the main ugliness about sched_attr is that
> > it is linux specific so you need linux specific api to
> > work with it. (pthread_* is posix namespace, not for linux).
>
> We can add pthread_*_np functions, there is precedent for that.
FWIW, I agree.
> What's unclear to me is what the expected evolution of struct
> sched_attr is. Is the description in the manual page accurate?
I'd say so. :-)
> If we had a pthread_attr_setschedattr_np function, it presumably would
> have to make a copy of the argument on the heap, to be consistent with
> other such functions. In order to make this future-proof, we would
> need a precise description of the extension mechanism, and a promise
> that later versions will not contain pointers (which would be unlikely
> for such kernel data structures, but it would not be entirely
> impossible to have them).
Man pages are accurate AFAICS [1].
One could also look at a proposed extension that is currently under
review (utilclamp [2]) to have an idea of how future further extensions
will be handled.
I don't see how pointers in there would be required, but I guess only
maintainers can make such a promise?
Thanks,
- Juri
1 - https://elixir.bootlin.com/linux/latest/source/kernel/sched/core.c#L4477
2 - https://lore.kernel.org/lkml/20180806163946.28380-2-patrick.bellasi@arm.com/