[Xenomai-help] driver migration

[Xenomai-help] driver migration

[Nilanjan Roychowdhury]

Hi,
I had a linux driver with functionalities like it blocks a thread on an
ioctl and wakes it up when an interrupt occurs and does some processing.
Now I want to migrate to xenomai space. Can I write a user  space device
driver for this like I create an user space rt_task and call
rt_intr_wait in the entry fuction of the task and whenever I get an
interrupt I wake up and do the processing. Will I have any performance
hit?? I will make sure the priority of this xenomai task is higher than
any other xenomai task as it will do some interrupt processing.

In general, if I need to migrate a traditional linux device driver with
only user space clients to xenomai space can I write a user - space
device driver ???

Under what scenario we place a driver as a kernel module in xenomai
space??
Thanks,
-Nilanjan

Re: [Xenomai-help] driver migration

[Jan Kiszka]

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

Nilanjan Roychowdhury wrote:
> 
> 
> Hi,
> I had a linux driver with functionalities like it blocks a thread on an
> ioctl and wakes it up when an interrupt occurs and does some processing.
> Now I want to migrate to xenomai space. Can I write a user  space device
> driver for this like I create an user space rt_task and call
> rt_intr_wait in the entry fuction of the task and whenever I get an
> interrupt I wake up and do the processing. Will I have any performance
> hit?? I will make sure the priority of this xenomai task is higher than
> any other xenomai task as it will do some interrupt processing.
> 
> In general, if I need to migrate a traditional linux device driver with
> only user space clients to xenomai space can I write a user - space
> device driver ???

You can. Both native and posix skin provide means to block a user-space
thread on an IRQ event. And if you already have a working user-space
driver, that step should be simple as there are likely no problems with
kernel-only services like DMA management.

It is planned to enhance the Real-Time Driver Model (RTDM) with
user-space support as well, keeping both the programming model for the
driver users (profiles) as well as for the driver developers as far as
feasible. The idea is to make drivers easily re-compilable/portable
between kernel and user-space - but that's something which cannot help
you yet.

> 
> Under what scenario we place a driver as a kernel module in xenomai
> space??

Performance will remain a reason to go to kernel-space, specifically if
you either share your device between multiple processes (having a driver
in a separate process comes at a price...) or if you need low latency on
IRQ handling. But there are also reasons to go to user-space, e.g.
license issues. We are trying to address both.

In any case, a clear separation between driver and application design is
highly recommended and something we try to foster with RTDM.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

RE: [Xenomai-help] driver migration

[Nilanjan Roychowdhury]

>Performance will remain a reason to go to kernel-space, specifically if
>you either share your device between multiple processes (having a
driver
>in a separate process comes at a price...) or if you need low latency
on
>IRQ handling. But there are also reasons to go to user-space, e.g.
>license issues. We are trying to address both.

Nilanjan :- Can I assume you are saying the latency is less when I run
my interrupt processing code as an real time ISR rather than a user -
space 
Thread ?
In that case I can run the ISR in kernel mode and signal the user space
RT task by a semaphore ( the user space task will bind this).


-----Original Message-----
From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
Sent: Thursday, September 14, 2006 2:57 PM
To: Nilanjan Roychowdhury
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] driver migration

Nilanjan Roychowdhury wrote:
> 
> 
> Hi,
> I had a linux driver with functionalities like it blocks a thread on
an
> ioctl and wakes it up when an interrupt occurs and does some
processing.
> Now I want to migrate to xenomai space. Can I write a user  space
device
> driver for this like I create an user space rt_task and call
> rt_intr_wait in the entry fuction of the task and whenever I get an
> interrupt I wake up and do the processing. Will I have any performance
> hit?? I will make sure the priority of this xenomai task is higher
than
> any other xenomai task as it will do some interrupt processing.
> 
> In general, if I need to migrate a traditional linux device driver
with
> only user space clients to xenomai space can I write a user - space
> device driver ???

You can. Both native and posix skin provide means to block a user-space
thread on an IRQ event. And if you already have a working user-space
driver, that step should be simple as there are likely no problems with
kernel-only services like DMA management.

It is planned to enhance the Real-Time Driver Model (RTDM) with
user-space support as well, keeping both the programming model for the
driver users (profiles) as well as for the driver developers as far as
feasible. The idea is to make drivers easily re-compilable/portable
between kernel and user-space - but that's something which cannot help
you yet.

> 
> Under what scenario we place a driver as a kernel module in xenomai
> space??

Performance will remain a reason to go to kernel-space, specifically if
you either share your device between multiple processes (having a driver
in a separate process comes at a price...) or if you need low latency on
IRQ handling. But there are also reasons to go to user-space, e.g.
license issues. We are trying to address both.

In any case, a clear separation between driver and application design is
highly recommended and something we try to foster with RTDM.

Jan

Re: [Xenomai-help] driver migration

[Jan Kiszka]

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

Nilanjan Roychowdhury wrote:
>> Performance will remain a reason to go to kernel-space, specifically if
>> you either share your device between multiple processes (having a
> driver
>> in a separate process comes at a price...) or if you need low latency
> on
>> IRQ handling. But there are also reasons to go to user-space, e.g.
>> license issues. We are trying to address both.
> 
> Nilanjan :- Can I assume you are saying the latency is less when I run
> my interrupt processing code as an real time ISR rather than a user -
> space 
> Thread ?

Yes, of course. Check the irqbench test for real numbers on your target
system.

> In that case I can run the ISR in kernel mode and signal the user space
> RT task by a semaphore ( the user space task will bind this).

That would be the classic design if you have some simple job to do on
IRQ delivery (some direct fiddling with the hardware e.g.) + you want to
wakeup a thread waiting on the event. In this case you can use RTDM for
the in-kernel part and attach your application to the RTDM device your
driver will then export.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

RE: [Xenomai-help] driver migration

[Nilanjan Roychowdhury]

Jan,
I have a question on RTDM. Lets say I have chosen Xenomai as the FIRST
platform to develop my driver with a plan to move my driver to an RTOS
in future. And lets say this RTOS does not have an IO system. Does not
understand any /dev/XXX entry. In that RTOS you have tasks waiting for
events and you post the events from an ISR ( lets say by a message
queue).

In that case, do you suggest I go for RTDM. Or I just try to mimic the
same RTOS behavior by RT interrupts and rt tasks ??
-Nilanjan

-----Original Message-----
From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid
Sent: Thursday, September 14, 2006 3:11 PM
To: Nilanjan Roychowdhury
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] driver migration

Nilanjan Roychowdhury wrote:
>> Performance will remain a reason to go to kernel-space, specifically
if
>> you either share your device between multiple processes (having a
> driver
>> in a separate process comes at a price...) or if you need low latency
> on
>> IRQ handling. But there are also reasons to go to user-space, e.g.
>> license issues. We are trying to address both.
> 
> Nilanjan :- Can I assume you are saying the latency is less when I run
> my interrupt processing code as an real time ISR rather than a user -
> space 
> Thread ?

Yes, of course. Check the irqbench test for real numbers on your target
system.

> In that case I can run the ISR in kernel mode and signal the user
space
> RT task by a semaphore ( the user space task will bind this).

That would be the classic design if you have some simple job to do on
IRQ delivery (some direct fiddling with the hardware e.g.) + you want to
wakeup a thread waiting on the event. In this case you can use RTDM for
the in-kernel part and attach your application to the RTDM device your
driver will then export.

Jan

Re: [Xenomai-help] driver migration

[Jan Kiszka]

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

Nilanjan Roychowdhury wrote:
> Jan,
> I have a question on RTDM. Lets say I have chosen Xenomai as the FIRST
> platform to develop my driver with a plan to move my driver to an RTOS
> in future. And lets say this RTOS does not have an IO system. Does not
> understand any /dev/XXX entry.

Neither had original Xenomai or RTAI in hard-RT mode. To define such
basic I/O system, RTDM was invented. It can (and does under those two
systems) provide a simple self-contained hard-RT I/O subsystem to build
drivers upon, but it would also work on systems where this is already
available (PREEMPT_RT will likely be such a candidate).

> In that RTOS you have tasks waiting for
> events and you post the events from an ISR ( lets say by a message
> queue).
> 
> In that case, do you suggest I go for RTDM. Or I just try to mimic the
> same RTOS behavior by RT interrupts and rt tasks ??

It's hard to say without knowing that RTOS, likely also its degree of
extensibility. But I could imagine that porting RTDM (or the parts you
actually use) over your RTOS would simplify your life when having to
maintain drivers for both systems. RTDM first of all defines abstract
RTOS services for drivers and a communication interface between drivers
and applications, both should be mappable on other systems as well.
Again, that's speculation, the devil can always be in the detail.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]