> Ok, general bottom line regarding IRQ support (and the rest):
>
> 1- we want the rules applicable to the common case to be simple, well-defined and
> straightforward. This applies to the ISR return value as exposed.
> 2- some requirements might fall outside of the common case; to support them, we
> need to refrain from imposing a strong policy, but only provide sound mechanisms
> to implement that. Specifically, let's keep the basic ability to control the Adeos
> pipelining from Xenomai intact.
> 3- however, let's be true to the good old UNIX way-of-life: there is no point in
> penalizing 99% of the common user base to please only 1% of them who happen to
> have very specific needs. E.g., don't slow down the fast path everyone takes,
> don't impose hard rules most of the users won't benefit from.

Ack.

> [I'm not referring
> to the enable/disable nesting count here: this _is_ correct, and is currently
> missing -- this should be done at Xeno's arch-level, not from the HAL which should
> be kept the way it is to have a direct, unmoderated access to the PIC handling].

Let's consider it a bit. The counter as well as XENO_IRQ_DISABLED bit (or something similar)
should be kept somewhere. So it's either xnintr_t or irq description in low-level
ipipe code; we just don't want to introduce new structures and probably
it's better to implement this feature on Xeno layer, rather than on ipipe one.

Actually, xnintr_t is not visible from arch-level code.

In order to support nested calls of irq_enable/disable, we should take additional control
in all places where irq_desc[irq]->handler->enable/disable() are used (ok, hal interface
is out of the scope, but e.g. xnintr_enable() and xnintr_disable() must be modified
appropriately not to use this hal interface).

Another thing is xnarch_irq_end() which re-enables the IRQ line upon exitting from
interrupt handling code.

It must make check for DISABLED bit (ISR might have called xnintr_disable() to defer
the IRQ line enabling).

For most part of the archs supported by Xeno, .ending (xnarch_irq_end()) is only about
calling irq_desc[irq]->handler->enable()
(handler->end() is never used) so it's not a problem to make a small wrapper
that re-enables the IRQ line only when XENO_IRQ_DISABLED bit is not set.

On ppc, irq_desc[irq]->handler->end() can be called indeed and we don't know
what's all about - at least, on the Xeno layer.

So either

handler->end() must check for XENO_IRQ_DISABLED - but this is an arch-level code
in Linux (i.e. not the Xeno layer);

or Xeno/arch/ppc must represent an .end substitution for each sub-arch supported.

 
> IOW, the patch, the way you discussed it recently, is ok for me too.

This said, I'm going to publish the shirq patch (after finalizing ISR return bits,
where I still have some doubts) without enable/disable nesting support.
It can be supported at some point of time later, if it's really needed.
 

--

Philippe.



--
Best regards,
Dmitry Adamushko
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to