Re: [Xenomai] [PATCH] Revert "ipipe: ipipe_request_irq(), ipipe_free_irq() are root-only services"

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-09-20 16:05, Philippe Gerum wrote:
>>>> In this light, let's remove those checks nevertheless.
>>>> Enabling/disabling the IRQ are separate calls, and those should be
>>>> instrumented as those cause the restriction.
>>>>
>>>
>>> I don't see it this way, because we can't predict what will be the
>>> constraints we might have for hooking irqs on all archs we will support.
>>> Maybe we will have to run more mainline code in some cases. In any case,
>>> we have to fold masking into the de-registration code for proper SMP
>>> support - this fix was never finalized precisely because we could not
>>> guarantee a root calling context in that case.
>>>
>>> These checks are there to express the fact that calling from non-root is
>>> inherently unsafe. We might find a (ugly) way to tag irq descriptors,
>>> for knowing whether this is safe to call from non-root and test this
>>> conditionally. But at the end of the day, we would still end up with
>>> checking for arch-specific constraints in a generic API, which would be
>>> wrong by design.
>>>
>>> I put these checks when refactoring the pipeline API for the very same
>>> reason than you agree to update the RTDM spec regarding
>>> rtdm_request_irq: no sane code should have called ipipe_virtualize_irq()
>>> from a non-root context. This is just about formalizing this fact.
>>
>> ...at the wrong point. Plus it is breaking our instrumentation. Again:
>> this belongs where we can asses the problem better, i.e. in the higher
>> layer and in those functions that do break when called from RT context.
> 
> I don't think so.

I do agree that the caller of ipipe_request_irq should not be called
over RT context. However, ipipe_request_irq itself _is_ called under an
RT spin lock with hardirqs disabled, both under Xenomai 2.6 and upcoming
3. And this triggers CONFIG_IPIPE_DEBUG_CONTEXT, clearly showing that
things are still broken here. What do you suggest to fix all this?

Jan

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