Re: Is adding a pthread wrapper for sched_{get,set}attr feasible?

[Florian Weimer <fw@deneb.enyo.de>]

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

What's unclear to me is what the expected evolution of struct
sched_attr is.  Is the description in the manual page accurate?

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