Re: [Xenomai-help] xnpod help

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

Brandt Erickson wrote:
 > > Ok, things get clearer. But why a kernel module? Are you *that* short on
 > > CPU cycles?
 > 
 > The reason why I'm trying to develop a kernel-space application is not for
 > latency issues but because I need to be in kernel-space to read/write
 > to/from my DAC.

There are several way you can write an application with Xenomai:
- first, the canonical way, split your application between driver code
  and application code, implement the driver in kernel-space and the
  application in user-space. Xenomai ease your work by providing the
  RTDM skin for writing drivers in kernel-space, and user-space skins
  (posix, native, vxworks, etc...) for writing applications in
  user-space. For a good portability, I would suggest to use the posix
  skin in user-space.

- second, the rapid way, good for prototyping, do it all in
  user-space. You may use iopl or ioperm to allow your application to
  access I/O regions, and libpci and mmaping /dev/mem to access PCI
  devices from user-space. Xenomai will ease your work here by allowing
  you to run your whole application in gdb, and skins generally provide
  functions to implement IRQ servers in user-space. See for example
  pthread_intr_wait_np.

- a third way, maybe useful as an intermediate between the first
  two. Split your code between kernel-space and user-space, but use
  the same skin in user-space and kernel-space. Xenomai ease your
  work here because skin interfaces are written to be very similar in
  kernel-space and user-space, and IPCs may generally be used to
  communicate between the two address spaces.

 >  Is the IPC between kernel-space realtime and user-space
 > non-realtime that much more difficult the user-space realtime to
 > user-space non-realtime?  I've familiar with regular user-space IPC using
 > condition variables, semaphores, and shared memory, so if it's fairly
 > similar, I'm hoping that won't be a problem.
 > -Brandt

The only IPC existing to communicate between real-time (whether
user-space or kernel-space) and non-realtime user-space threads is the
native skin message pipes: 
http://www.xenomai.org/documentation/trunk/html/api/group__pipe.html

By contrast all other IPC implemented by all skins are accessible to
real-time threads running in secondary mode: they will simply switch to
primary mode the time they use blocking services. So, it is probably a
better idea to create your non-realtime threads as real-time threads and
let them switch to secondary mode when they use non-realtime services.

-- 


					    Gilles Chanteperdrix.