Re: [Xenomai] [Xenomai-git] Jan Kiszka : cobalt/kernel: Introduce __SCHED_CURRENT policy to setschedparam_ex

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2016-05-24 09:03, Gilles Chanteperdrix wrote:
> On Mon, May 23, 2016 at 03:29:09PM +0200, Jan Kiszka wrote:
>> On 2016-05-23 15:09, Gilles Chanteperdrix wrote:
>>> On Mon, May 23, 2016 at 02:51:39PM +0200, Jan Kiszka wrote:
>>>> On 2016-05-23 14:44, Gilles Chanteperdrix wrote:
>>>>> On Mon, May 23, 2016 at 02:22:12PM +0200, Jan Kiszka wrote:
>>>>>> On 2016-05-23 14:07, Gilles Chanteperdrix wrote:
>>>>>>> On Mon, May 23, 2016 at 12:40:00PM +0200, git repository hosting wrote:
>>>>>>>> Module: xenomai-3
>>>>>>>> Branch: next
>>>>>>>> Commit: c821cbaa31c4a816615a82d7cbbd049987da6f1a
>>>>>>>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=c821cbaa31c4a816615a82d7cbbd049987da6f1a
>>>>>>>>
>>>>>>>> Author: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>> Date:   Tue Mar  8 14:41:28 2016 +0100
>>>>>>>>
>>>>>>>> cobalt/kernel: Introduce __SCHED_CURRENT policy to setschedparam_ex
>>>>>>>>
>>>>>>>> Define the internal scheduling policy "current": it shall refer to the
>>>>>>>> target thread's current scheduling policy. This will allow to model
>>>>>>>> pthread_setschedprio on top of pthread_setschedparam_ex with only a
>>>>>>>> single syscall.
>>>>>>>
>>>>>>> I am not sure I understand the use of __SCHED_CURRENT all that well.
>>>>>>> Since different scheduling policies have different priority ranges,
>>>>>>> a particular priority may only make sense for a couple of scheduling
>>>>>>> policies. This, means, to use __SCHED_CURRENT, the programmer has to
>>>>>>> know the scheduling policy of the current thread anyway. So, since
>>>>>>> he knows it, why not specifying it clearly? This will make the
>>>>>>> application code more readable, will not change anything with regard
>>>>>>> to the number of calls, and avoid to have to change Xenomai core.
>>>>>>
>>>>>> See "Wrap pthread_setschedprio for proper real-time support" for the use
>>>>>> case. I'm open to address that one differently, via a separate syscall
>>>>>> or whatever, if preferred. This one was just most simple.
>>>>>
>>>>> Ok, my point shift to: de we need to support pthread_setschedprio()?
>>>>
>>>> Yes, for existing programs that we want to support over Xenomai without
>>>> modifying them.
>>>>
>>>>> The programmer has to know the target thread scheduling policy to be
>>>>> able to call that function sanely, so why not using
>>>>> pthread_setschedparam instead, which has a "self documenting" effect
>>>>> on indicating clearly which policy the target thread is using?
>>>>
>>>> Think of a layer that has no knowledge if the caller has SCHED_RR or
>>>> SCHED_FIFO set (or any other policy that have compatible prio scales)
>>>> but needs to adjust only the prio. That's the scenario we have to deal with.
>>>
>>> Your argument seems to always be the same: "my application is badly
>>> designed, let us fix it in Xenomai core". What about fixing your
>>> application for a change?
>>
>> It's a) not badly designed and b) it's Xenomai's role to enable
>> application porting as seamlessly as possible. So I don't see any value
>> in NOT providing this POSIX interface now also without migrations. It's
>> there anyway, it's usable, it's just lacking migration-free support.
> 
> It is not there an all platforms it seems:
> https://xenomai.org/build-test-next/distcheck-bfin-linux-uclibc-gcc-4.3.5/cobalt/log.html#1
> 

Hmm, is it somehow configurable there? I don't have this setup around, I
just see pthread_setschedprio being part of the uclibc code base
(https://git.busybox.net/uClibc/log/libpthread/nptl/pthread_setschedprio.c).
Confused.

Yes, needs probing if there isn't any implementation available on that
platform. Will push an update.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux