Common Driver Model for RTAI
kiszka at rts.uni-hannover.de
Fri Jul 1 14:51:11 CEST 2005
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > [off-topic] Shared memory between kernel und user space POSIX
> > applications? What more beyond the existing mmap will be needed? To
> > setup shm between fusion processes, standard mmap already works, there
> > is nothing special in my eyes.
> Kernel-space and user-space have to share the same namespace for
> shm_open. There are two ways to do this, one is to have an RTAI-only
> namespace, and to implement an mmap for user-space pretty much the same
> way as rt_heap_bind for the native skin.
And the other way around: write some compatible mmap for kernel space
that works against regular mmap? You would only have to exclude that it
gets called from rt-contexts.
> > > You said that each driver has a set of non-rt entry points. So, I
> > > imagined, but I may be wrong, that these entry points are use to map
> > > usual Linux device file descriptors to RTDM drivers. Now the question
> > > was about how this mapping was done.
> > >
> > The non-rt entry points are not mapped to the standard Linux namespace.
> > You are just free (as far as the driver supports it) to call the RTDM
> > API also from non-rt contexts. Tthat's all. No magic here.
> But if I understood correctly, the RTDM API is the same as the standard
> API. You mean that there is an RTDM version of "select" which can not
> sleep on standard file descriptors ?
That's the current situation.
It's always good to have other people looking at it from different
perspective. What you suggest might be useful and might also be
feasible, but it will require more effort - more than what was spent on
this by-product of the RTDM concept yet. There may be some use cases for
non-rt threads directly accessing rt-devices, but the mass will do this
from RTAI contexts without the need to have an eye on both rt and non-rt
More information about the Rtai