Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Jan Kiszka wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>>>>> Jan Kiszka wrote:
>>>>>>>>> @@ -192,6 +192,9 @@ static void *__pthread_trampoline(void *arg)
>>>>>>>>>
>>>>>>>>> param.sched_priority = iargs->prio;
>>>>>>>>> policy = iargs->policy;
>>>>>>>>> + if (policy == SCHED_RR)
>>>>>>>>> + /* Restrict round-robin scheduling to the Xenomai
>>>>>>>>> domain. */
>>>>>>>>> + policy = SCHED_FIFO;
>>>>>>>> Should not there be the same thing in __wrap_pthread_setschedparam ?
>>>>>>> Yes, and setschedparam_ex, here we go:
>>>>>> Actually, I am wondering if we can not get rid of these calls to
>>>>>> __real_pthread_setschedparam, now that propagating kernel-space priority
>>>>>> to user-space is done by a signal ?
>>>>> Not with the existing code, as that only forwards prio changes, but no
>>>>> policy changes.
>>>> If we map SCHED_RR to SCHED_FIFO, are there any policy changes?
>>> Yes, the initial one. Keep in mind that not all pthread implementations
>>> may respect the pthread_attr or have problems assigning SCHED_FIFO to
>>> threads of non-root users.
>> Ok. What about calling xnshadow_renice in xnshadow_map ?
>
> Sorry, I can't follow. xnshadow_renice does not help user space to find
> the right policy, or what do you mean?
xnshadow_renice sends a signal to the user-space thread which in turn
calls __real_pthread_setschedparam.
The advantage of this solution is that it avoids calling
__real_pthread_setschedparam in many places in the user-space skins.
--
Gilles.
_______________________________________________
Xenomai-core mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-core
