Re: [Xenomai-help] RTDM and user space hardware drivers

[Jan Kiszka <jan.kiszka@domain.hid>]

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

M. Koehrer wrote:
> Hi everybody,
> 
> the RTDM API is really very good as API for drivers. 
> I have a real time (Xenomai) application in user space that has to access PCI boards.
> The "classical" approach is now to use a kernel driver and to use RTDM as interface
> between the user space application an the kernel space driver.
> However, for performance issues, I prefer to write a pure user mode driver.
> As the memory of the PCI board can be accesses from user space (using /dev/mem) 
> I want to write a pure user space driver  as this seems to me more efficient (and easier to debug) than
> a kernel driver.
> Also, only one application is accessing the driver at a time, I can link the driver directly to my application.
> 
> My questions are now:
> 1. Is it possible to use the RTDM API also for pure user space drivers?

There is no RTDM driver API exported to user space yet, it's still just
a plan for the future.

> 
> 2. Is there any experience concerning the performance of a user space driver versus a kernel space
> driver?
> In my use case, I have to write and read about 60 byte (each direction) of (block) data to/from the PCI I/O system.

User space drivers can improve performance if you transfer a lot of data
and save potential user/kernel copy-steps this way (though, zero-copy
can also be realised with kernel drivers) or if you do a lot of driver
calls and the call-overhead becomes noticeable. This works fairly well
for exclusive devices (only one user process at a time). But once you
have to share/multiplex a devices, performance quickly becomes worse.

When going for a user space driver design, make sure you keep a clean
separation between driver and application. [It will be one major goal of
an RTDM for user space to support driver writers in this regard.]

Jan


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