Common Driver Model for RTAI

[Jan Kiszka]

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

Jan