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

[Juri Lelli <juri dot lelli at redhat dot com>]

Hi,

Thanks for your prompt reply.

On 22/08/18 15:03, Szabolcs Nagy wrote:
> On 22/08/18 14:15, Juri Lelli wrote:
> > During a recent discussion on linux-rt-users mailing list [1] was
> > pointed out that adding a pthreads wrapper around sched_{get,set}attr
> > syscalls would make life a little easier (and code cleaner?) for users
> > of such interface.
> > 
> > One can of course easily use the interface by doing gettid() and calling
> > syscall() - e.g., [2] - but properly supporting the same interface in
> > standard libraries might be to prefer, as it would also align with the
> > existing pthread_attr_setschedparam(), etc.
> > 
> > I researched a bit the archives, but couldn't find anything related to
> > this question. Any pointers? Any thoughts about the feasibility of
> > adding such support?
> > 
> 
> a linux specific syscall wrapper may work, but it can be done
> without a new api as well:
> 
> the existing pthread_attr_setschedparam can be used, but the abi and api
> has to change, so new symbol versions and feature test macros have to
> be added (similar to the _POSIX_THREAD_SPORADIC_SERVER macro in unistd.h)
> 
> glibc misses some members in struct sched_param that are required
> for the new linux specific SCHED_* policy. (e.g. posix specifies
> further members for SCHED_SPORADIC which is currently not implemented
> by linux, but once that's implemented the members have to be added)
> 
> then pthread_attr_setschedparam could internally call the new
> linux syscalls.

OK, I guess I'm still wondering though if a new
pthread_attr_{set,get}schedattr() wouldn't be to prefer, as
sched_{set,get}attr are supersets of sched_{set,get}param and not the
other way around?

Best,

- Juri