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

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

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.
https://click-hack.org

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

[Jan Kiszka]

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.

Jan

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

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

[Gilles Chanteperdrix]

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()?
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?

-- 
					    Gilles.
https://click-hack.org

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

[Jan Kiszka]

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.

Jan

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

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

[Gilles Chanteperdrix]

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?

-- 
					    Gilles.
https://click-hack.org

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

[Jan Kiszka]

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.

Jan

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

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

[Gilles Chanteperdrix]

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.

As I said. I find this interface bad. So I am going to try and
explain it a third time, in a different way.

pthread_setschedprio(0)

only works if the thread is running with the SCHED_OTHER policy.

pthread_setschedprio(1)

only works if the thread is running with the SCHED_FIFO or SCHED_RR
policy.

So, in order to be able to use pthread_setschedprio() sanely, the
programmer has to KNOW what is the current policy of the thread. So,
if he knows it, it seems better to use pthread_setschedparam().

-- 
					    Gilles.
https://click-hack.org

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

[Gilles Chanteperdrix]

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

-- 
					    Gilles.
https://click-hack.org

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

[Jan Kiszka]

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

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

[Gilles Chanteperdrix]

On Tue, May 24, 2016 at 11:12:52AM +0200, Jan Kiszka wrote:
> 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.

I believe Philippe pushed a fix on the next branch.

-- 
					    Gilles.
https://click-hack.org