Re: [Xenomai] [PATCH v3] nucleus: Convert intrlock to a sleeping Linux lock

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 01/06/2013 04:19 PM, Jan Kiszka wrote:

> On 2013-01-06 16:15, Gilles Chanteperdrix wrote:
>> On 01/06/2013 04:11 PM, Jan Kiszka wrote:
>>
>>> On 2013-01-06 16:09, Gilles Chanteperdrix wrote:
>>>>> If you prefer to skip the warning in ipipe, then I will send a
>>>>> corresponding patch. The lock conversion is still necessary for forge,
>>>>> though.
>>>>
>>>>
>>>> There are other ways around, ipipe_virtualize_irq is already a wrapper
>>>> used only by 2.6, so we can add some code here. So, we can only check
>>>> ipipe_root_p here, and disable the warning in ipipe_request_irq.
>>>
>>> Err, we rather need unchecked __ipipe_request_irq, called by
>>> ipipe_request_irq after testing the context and by ipipe_virtualize_irq
>>> without that test.
>>
>>
>> ipipe_root_only does two tests, it tests whether the current domain is
>> root, and whether root is stalled. The problem, as far as I understood,
>> come from the second test, what I mean is that we can arrange to keep
>> the first test for ipipe_virtualize_irq.
> 
> Well, if we disallow non-root invocations of ipipe_virtualize_irq, then
> we can also convert the lock to a Linux version. I thought your concerns
> are related to restricting the usage of that services (or services that
> call it) in stable 2.6.


No, my concerns are about the many regression that turning a spinlock
into a mutex could bring. If turning a spinlock into a mutex was such a
harmless matter, maybe the -rt patch would have been merged for years
;-)

Your patches changes some behaviour, for instance, with the current
implementation, if an interrupt is taken while reading cat
/proc/xenomai/irq, the display to /proc is restarted, after your patch,
this behaviour changes. I do not think that it matters, but you get the
point: there are many consequences possible with this change, yet
unforeseen but which will pop up as soon as people start using the
modified version and cause us to keep working on 2.6 whereas we should
be working on -forge.

Besides, if 2.6 benefits from all the changes made to the I-pipe core,
what will be left to advertise when 3.0 is out ;-)

-- 
                                                                Gilles.