[Xenomai] Xenomai 3 vs 2.6: rtdm_irq_request() calling task context change

[Xenomai] Xenomai 3 vs 2.6: rtdm_irq_request() calling task context change

[Stephane Grosjean]

Hi,

https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ says:

"rtdm_irq_request/free() and rtdm_irq_enable/disable() call pairs must 
be called from a Linux task context, which is a restriction that did not 
exist previously with Xenomai 2.x."

and, a few lower lines:

"Since allocating, releasing, enabling or disabling real-time interrupts 
is most commonly done from driver initialization/cleanup context already,"

I was not aware about these Linux kernel driver requirements... On the 
contrary, regarding linux-can drivers (for example), the IRQ is 
requested when the device is opened only, not when it is probed. An it 
is freed when the device is closed. In my mind, this was a good choice 
because it avoids useless chained ISRs during the times the devices are 
not opened. So, the above assumption is a little rough, IMHO...

Anyway, this is how new things are... Any advice for us not to change 
the whole architecture of our driver will be welcome.

Stéphane


--
PEAK-System Technik GmbH
Sitz der Gesellschaft Darmstadt - HRB 9183 
Geschaeftsfuehrung: A.Gach, U.Wilhelm
--

Re: [Xenomai] Xenomai 3 vs 2.6: rtdm_irq_request() calling task context change

[Gilles Chanteperdrix]

On Tue, Jun 21, 2016 at 11:22:37AM +0200, Stephane Grosjean wrote:
> Hi,
> 
> https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ says:
> 
> "rtdm_irq_request/free() and rtdm_irq_enable/disable() call pairs must 
> be called from a Linux task context, which is a restriction that did not 
> exist previously with Xenomai 2.x."
> 
> and, a few lower lines:
> 
> "Since allocating, releasing, enabling or disabling real-time interrupts 
> is most commonly done from driver initialization/cleanup context already,"
> 
> I was not aware about these Linux kernel driver requirements...

These are Xenomai requirements, not Linux kernel driver requirements.

> On the 
> contrary, regarding linux-can drivers (for example), the IRQ is 
> requested when the device is opened only, not when it is probed. An it 
> is freed when the device is closed.

the ->open_rt and ->close_rt callbacks in RTDM drivers have not been
used in in-tree RTDM drivers for some time in 2.x. In 3.x, this is
official, you can no longer implement primary mode open/close, see:
https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/#Updated_device_operation_descriptor

So, open and close can be considered initialization/cleanup context.

>  In my mind, this was a good choice 
> because it avoids useless chained ISRs during the times the devices are 
> not opened. So, the above assumption is a little rough, IMHO...
> 
> Anyway, this is how new things are... Any advice for us not to change 
> the whole architecture of our driver will be welcome.

I believe you do not need to change the whole architecture of your
driver.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Xenomai 3 vs 2.6: rtdm_irq_request() calling task context change

[Philippe Gerum]

On 06/21/2016 11:22 AM, Stephane Grosjean wrote:
> Hi,
> 
> https://xenomai.org/migrating-from-xenomai-2-x-to-3-x/ says:
> 
> "rtdm_irq_request/free() and rtdm_irq_enable/disable() call pairs must
> be called from a Linux task context, which is a restriction that did not
> exist previously with Xenomai 2.x."
> 
> and, a few lower lines:
> 
> "Since allocating, releasing, enabling or disabling real-time interrupts
> is most commonly done from driver initialization/cleanup context already,"
> 
> I was not aware about these Linux kernel driver requirements... On the

The mainline kernel does not have to deal with dual kernel issues, by
definition.

> contrary, regarding linux-can drivers (for example), the IRQ is
> requested when the device is opened only, not when it is probed. An it
> is freed when the device is closed. In my mind, this was a good choice
> because it avoids useless chained ISRs during the times the devices are
> not opened.

Your issue is about depending on open_rt() which is long gone, nothing
prevents you from hooking IRQs from the current open() handler. If you
expected IRQ hooking services to meet any sort of real-time requirement,
then you were wrong, they just can't. Hooking the IRQ from the open()
handler will just work.

> So, the above assumption is a little rough, IMHO...
> 

Xenomai relies on the linux kernel internals for IRQ
installation/cleanup duties, which can only be called from a plain Linux
context for common hardware such as chip controllers depending on the
PCI framework. Enabling/disabling IRQ channels have the same
requirement. Even more services we need during these specific phases
also have the very same requirement.

Some code may have been lucky enough to run IRQ installation/cleanup
calls from RT context without any issue, only due to the underlying
interrupt controller code not traversing regular Linux locking constructs.

In addition, there are cases when it is simply not possible to disable
an IRQ channel safely from a RT context.

All these issues have been identified over the years and discussed on
this mailing list several times, the related changes address them.

-- 
Philippe.