Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> If shadowed Linux tasks with SCHED_RR policy change their priority,
>> do_setsched_event currenty ignores this. Extend the condition to catch
>> this case as well.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> ksrc/nucleus/shadow.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index bd3bb3d..9f81c32 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -2312,7 +2312,7 @@ static inline void do_setsched_event(struct
>> task_struct *p, int priority)
>> union xnsched_policy_param param;
>> struct xnsched *sched;
>>
>> -if (!thread || p->policy != SCHED_FIFO)
>> +if (!thread || (p->policy != SCHED_FIFO && p->policy != SCHED_RR))
>> return;
>
> After some thinking about it, I think this is the wrong way to go. When
> the user-space requests SCHED_RR, only the shadow should use SCHED_RR,
> the linux thread should keep using SCHED_FIFO. We do not want two
> schedulers to do round-robin, this would result in unpredictable behaviour.
Well, passing SCHED_FIFO instead of SCHED_RR to glibc is one thing. But
as you can't enforce this mapping anyway, I don't think it is wrong to
accept also prio changes of SCHED_RR shadow threads.
Jan
--
Siemens AG, Corporate Technology, CT SE 26
Corporate Competence Center Embedded Linux
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
