[Xenomai-core] __pse51_get_current_prio

[Xenomai-core] __pse51_get_current_prio

[Jan Kiszka]

Hi Gilles,

we've integrated your unit_mutex and our native test, but now we
stumbled over that __pse51_get_current_prio special syscall to check the
dynamic thread priority (during pi tests). I guess that service only
exists in your private patch queue? What are your plans about this in
case we want to push the mutex test into mainline? Or should we check
the thread prio indirectly (by waking up a lower-prio thread)?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] __pse51_get_current_prio

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Hi Gilles,
> 
> we've integrated your unit_mutex and our native test, but now we
> stumbled over that __pse51_get_current_prio special syscall to check the
> dynamic thread priority (during pi tests). I guess that service only
> exists in your private patch queue? What are your plans about this in
> case we want to push the mutex test into mainline? Or should we check
> the thread prio indirectly (by waking up a lower-prio thread)?

I had plan to remove this from unit_mutex. OTOH, it may come in handy if
we start breaking the xnsynchs...

-- 
                                                 Gilles.

Re: [Xenomai-core] __pse51_get_current_prio

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi Gilles,
>>
>> we've integrated your unit_mutex and our native test, but now we
>> stumbled over that __pse51_get_current_prio special syscall to check the
>> dynamic thread priority (during pi tests). I guess that service only
>> exists in your private patch queue? What are your plans about this in
>> case we want to push the mutex test into mainline? Or should we check
>> the thread prio indirectly (by waking up a lower-prio thread)?
> 
> I had plan to remove this from unit_mutex. OTOH, it may come in handy if
> we start breaking the xnsynchs...

Maybe one could invent some "pthread_inquire_np" so that the usefulness
of this extension increases beyond unit tests.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] __pse51_get_current_prio

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Hi Gilles,
>>>
>>> we've integrated your unit_mutex and our native test, but now we
>>> stumbled over that __pse51_get_current_prio special syscall to check the
>>> dynamic thread priority (during pi tests). I guess that service only
>>> exists in your private patch queue? What are your plans about this in
>>> case we want to push the mutex test into mainline? Or should we check
>>> the thread prio indirectly (by waking up a lower-prio thread)?
>> I had plan to remove this from unit_mutex. OTOH, it may come in handy if
>> we start breaking the xnsynchs...
> 
> Maybe one could invent some "pthread_inquire_np" so that the usefulness
> of this extension increases beyond unit tests.

Ok. What about splitting struct sched_param contents into two (16 bits)
members ? This way we would get the two priorities with an only
pthread_get_schedparam syscall.
On the other hand, when using pthread_inquire_np, we could get some more
insteresting information such as the task name, its current wchan, the
mutexes it holds etc...

-- 
					    Gilles.

Re: [Xenomai-core] __pse51_get_current_prio

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Hi Gilles,
>>>>
>>>> we've integrated your unit_mutex and our native test, but now we
>>>> stumbled over that __pse51_get_current_prio special syscall to check the
>>>> dynamic thread priority (during pi tests). I guess that service only
>>>> exists in your private patch queue? What are your plans about this in
>>>> case we want to push the mutex test into mainline? Or should we check
>>>> the thread prio indirectly (by waking up a lower-prio thread)?
>>> I had plan to remove this from unit_mutex. OTOH, it may come in handy if
>>> we start breaking the xnsynchs...
>> Maybe one could invent some "pthread_inquire_np" so that the usefulness
>> of this extension increases beyond unit tests.
> 
> Ok. What about splitting struct sched_param contents into two (16 bits)
> members ? This way we would get the two priorities with an only
> pthread_get_schedparam syscall.
> On the other hand, when using pthread_inquire_np, we could get some more
> insteresting information such as the task name, its current wchan, the
> mutexes it holds etc...

The latter use was precisely my idea. We would be talking about a
debugging interface via which we could collect as much
(Xenomai-specific) information about some thread as available (and
relevant to user space).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]