On 2013-01-06 16:26, Gilles Chanteperdrix wrote:
> 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.

This change was broken, the next version (or the one for forge) will not
do this mistake.

> 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.

I cannot chose yet where I'd like to work on. Getting a working combo of
Xenomai 2.6 with kernel 3.x will hopefully give us the room to move on.

Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: 
<http://www.xenomai.org/pipermail/xenomai/attachments/20130106/ef0fe961/attachment.pgp>
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to