[Xenomai-help] rtdm_printk

[Xenomai-help] rtdm_printk

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 110 bytes --]

When writing a RTDM kernel module driver, when must rtdm_printk() be used
instead of printk() ?

thanks,
Jeff

[-- Attachment #2: Type: text/html, Size: 123 bytes --]

Re: [Xenomai-help] rtdm_printk

[Gilles Chanteperdrix]

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...

-- 
                                                                Gilles.

Re: [Xenomai-help] rtdm_printk

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai-help] rtdm_printk

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]

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?


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?

thanks,
Jeff

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: [Xenomai-help] rtdm_printk

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] rtdm_printk

[Jeff Weber]

[-- Attachment #1: Type: text/plain, Size: 3627 bytes --]

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?

Jeff

[-- Attachment #2: Type: text/html, Size: 4511 bytes --]

Re: [Xenomai-help] rtdm_printk

[Gilles Chanteperdrix]

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.