Re: [Xenomai-help] rtdm_printk

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

Jeff Weber wrote:
> On Thu, Mar 10, 2011 at 7:03 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> Gilles Chanteperdrix wrote:
>>> Jeff Weber wrote:
>>>> When writing a RTDM kernel module driver, when must rtdm_printk() be
>> used
>>>> instead of printk() ?
>>> If RTDM was, one day, ported over something else than a Linux
>>> kernel-space based solution (for instance, over a port of Xenomai
>>> without Linux, or in Linux user-space), then you would not have to
>>> change your driver codeto have it compile over that new port.
>>>
>>> Until then, printk and rtdm_printk are identical.
>>>
>>> Note that the first paragraph is something very hypothetical, because in
>>> an RTDM driver, you generally have some other Linux kernel-space
>>> specific code, such as for instance the registration as a PCI driver,
>>> though the necessary parts of the Linux API could be implemented for
>>> that hypothetical port. But in that case, so could printk.
>>>
>>> So...
>> I guess the real reason for rtdm_printk is that at some point in the
>> past (probably before the Adeos era), printk was not safe to be called
>> from the real-time domain. In that case, rtdm_printk would be safe to be
>> called from the real-time domain. So, the answer is that you should use
>> rtdm_printk if you are calling from a Xenomai domain interrupt handler,
>> or from the context of a thread running in primary mode.
>>
>>
> What happens when a driver executes a non-realtime kernel function, from a
> Xenomai domain interrupt handler, or from the context of a thread running in
> primary mode?  Say the driver executes kmalloc() instead of rtdm_malloc(),
> or copy_to_user() instead of rtdm_copy_to_user().  Hopefully these are
> better examples than [rtdm_]printk() .
> 
> Does the offending user space thread transition to secondary mode?
> 
> What happens to the offending interrupt handler?
> 
> Do the notions of primary, secondary mode apply to the kernel as well?

The notion of primary, secondary mode applies to user-space Xenomai
threads. However, the mechanism used to automatically switch between
primary and secondary mode is the system calls handling. So, in short,
if you already are in kernel-space and call a non-realtime compatible
linux kernel function, you risk anything from fault to lockup, or debug
message if you have I-pipe debugging enabled. Daemons are flying around
your nose.

> 
> 
> Perhaps it's easier not analyze, separate all the non/realtime driver
> contexts, and always use the rtdm_ functions; say rtdm_malloc() everywhere
> in the driver (never use kmalloc).  Would this practice work?

It is not really hard, in a driver, to know whether you are in the
Xenomai or Linux domain. Everything executed by Linux is executing in
Linux domain (so init_module, exit_module, any callback you register to
a Linux subsystem, such as pci), as well as the _nrt callbaccks of an
RTDM driver. Irq handlers registered with rtdm_irq_request aand the _rt
callbacks registered in RTDM drivers/protocol are executed in primary
domain.

-- 
					    Gilles.