Common Driver Model for RTAI

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > 
>  > > What about mmap ?
>  > 
>  > I'm not yet convinced that there are enough useful scenarios for a 
>  > real-time mmap. Often mmap and the underlying implementations at driver 
>  > level have to tightly interact with the Linux VM subsystem - which is 
>  > not possible under RT constraints.
> 
> My only argument about mmap, is that it is standard, and that I will
> need it for implementing shared memory in the POSIX skin :-) mmap would

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

> just be the standard way to extend the use of RTAI shared memory to
> hardware mappings.
> 

The question is how much standard can be saved when we are not able to 
touch the VM during runtime (in rt-context). I must confess I haven't 
thought about memory mapping that intensively yet. I started recently 
just a little bit when thinking about a potential RTDM profile for 
Interbus cards. Ok, this topic definitely requires more brain work.

> 
>  > To me it appears more efficient to set timeouts via a separate channel, 
>  > typical specific IOCTLs. This way you are also free to define them 
>  > slightly differently (e.g. inter-message timeouts) per device class. 
>  > But, you are totally correct, we need them, and they have to be 
>  > specified within the Device Profiles.
> 
> This approach reminds me of a famous code snippet showing how to
> use correctly setitimer and SIGALRM to set a timeout on read and write:
> there is such a potential for races, that the result is an ugly tense
> piece of code, whereas adding a timeout argument to functions is so
> simple. It is in one of Steven's book. I guess it is not by pure chance
> that all recent posix interfaces have "timed" calls, as well as all
> legacy RTOS interfaces.
> 

Yes, I see. But I did not suggest to use signals as timeout helpers. 
Signals are generally a bit problematic for clean designs.

>  > >  > (...)
>  > >  >   o two entry points for each call: rt and non-rt
>  > >  >     (can point to the same handler or can be NULL if
>  > >  >     unsupported)
>  > >  >  (...)
>  > > 
>  > > Just being curious, how is the link with Linux implemented ? Do the
>  > > callbacks provided in the rtm_device structure follow Linux driver
>  > > interface, or do you use some sort of glue ?
>  > 
>  > There is no such thing as a simple porting concept for Linux drivers to 
>  > RTDM. That's foremost due to the fact that you have to analyse and 
>  > differentiate between RT and non-RT capable operations of your driver. 
>  > Is that what you were asking for? I'm not sure I understood your 
>  > question correctly.
> 
> 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.

Jan