Re: [Xenomai-help] rtdm_printk

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

Jeff Weber wrote:
> On Thu, Mar 10, 2011 at 12:27 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> 
>> 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.
>>
>> Say I have a driver utility function that can be called indirectly from
> either RT or NRT contexts, and say this function in turn needs to allocate
> kernel memory.  Can the function safely call rtdm_malloc regardless of the
> context?  Or, must the code test for the NRT/RT context and call kmalloc()
> or rtdm_malloc() appropriately?

You can not call in Linux domain any function which suspends its caller
such as rtdm_event_wait. But rtdm_malloc is ok. Every function documents
in the API documentation, from which contexts it can be called. See for
instance:
http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__util.html#g34dfd5c060c67acc684eb4b4256cd4ba

-- 
					    Gilles.