Messages in this thread | | | Date | Mon, 12 May 2014 14:24:52 +0200 | From | Peter Zijlstra <> | Subject | Re: SCHED_DEADLINE, sched_getscheduler(), and sched_getparam() |
| |
On Mon, May 12, 2014 at 02:09:58PM +0200, Michael Kerrisk (man-pages) wrote: > Hi Peter, > > Looking at the code of sched_getparam() and sched_setscheduler() (to > see what might need to land in the man pagea with respect to > SCHED_DEADLINE changes), I see that the former fails (EINVAL) if the > target is a SCHED_DEADLINE process, while the latter succeeds > (returning SCHED_DEADLINE). > > The sched_setscheduler() seems fine, but what's the rationale for > having sched_getparam() fail in this case, rather than just returning > a sched_priority of zero (since sched_priority is in any case unused, > as for SCHED_OTHER, right)? My point is that the change seems to > needlessly break applications that employ sched_getparam(). Maybe I am > missing something...
s/setscheduler/getscheduler/ ?
I'm a proponent of fail hard instead of fail silently and muddle on.
And while we can fully and correctly return sched_getscheduler() we cannot do so for sched_getparam().
Returning sched_param::sched_priority == 0 for DEADLINE would also break the symmetry between sched_setparam() and sched_getparam(), both will fail for SCHED_DEADLINE.
| |