Re: [Xenomai] Philippe Gerum : cobalt/thread: generalize usage of -> lock_count for preemption control

Re: [Xenomai] Philippe Gerum : cobalt/thread: generalize usage of -> lock_count for preemption control

[Jan Kiszka]

On 2015-07-02 09:41, git repository hosting wrote:
> Module: xenomai-3
> Branch: next
> Commit: 97e32440e9675ba91cdf80b320a35979b935dd8c
> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=97e32440e9675ba91cdf80b320a35979b935dd8c
> 
> Author: Philippe Gerum <rpm@xenomai.org>
> Date:   Tue Jun 30 20:36:25 2015 +0200
> 
> cobalt/thread: generalize usage of ->lock_count for preemption control
> 
> XNLOCK is uselessly mirroring only part of the information
> ->lock_count conveys.
> 
> We only need to keep XNLOCK as a mode bit in the ABI between the
> Cobalt core and lib/cobalt for switching the lock from user-space,
> using ->lock_count internally for testing the current preemption
> state.
> 

What about the mode listing in /proc/xenomai/sched/threads? I think it
will not work anymore right now, but likely it's useful to keep this.
The registry daemon should be fine as it builds on top of the
user/kernel ABI, right?

Jan

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

Re: [Xenomai] Philippe Gerum : cobalt/thread: generalize usage of -> lock_count for preemption control

[Philippe Gerum]

On 07/02/2015 03:37 PM, Jan Kiszka wrote:
> On 2015-07-02 09:41, git repository hosting wrote:
>> Module: xenomai-3
>> Branch: next
>> Commit: 97e32440e9675ba91cdf80b320a35979b935dd8c
>> URL:    http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=97e32440e9675ba91cdf80b320a35979b935dd8c
>>
>> Author: Philippe Gerum <rpm@xenomai.org>
>> Date:   Tue Jun 30 20:36:25 2015 +0200
>>
>> cobalt/thread: generalize usage of ->lock_count for preemption control
>>
>> XNLOCK is uselessly mirroring only part of the information
>> ->lock_count conveys.
>>
>> We only need to keep XNLOCK as a mode bit in the ABI between the
>> Cobalt core and lib/cobalt for switching the lock from user-space,
>> using ->lock_count internally for testing the current preemption
>> state.
>>
> 
> What about the mode listing in /proc/xenomai/sched/threads? I think it
> will not work anymore right now, but likely it's useful to keep this.

Correct, this needs fixing too. I'm working on moving XNLBALERT out of
the way, so that we may stop grabbing the big fat lock over xnlock
entirely, which will be nice to rtdm_lock* services.

> The registry daemon should be fine as it builds on top of the
> user/kernel ABI, right?
> 

Same issue than above: we still need to convert a non-zero lock_count to
XNLOCK in the state flags returned to userland.

-- 
Philippe.