Common Driver Model for RTAI

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > 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.

The problem is rather race conditions, because events can occur between
the time when a timer is set (whether with setitimer or with a specific
ioctl) and the time when read or write are called. If the timer ever
elapses before read or write are called, the caller gets blocked forever,
and to avoid that, the Stevens' book solution is to setjmp before
setting the timer, and to longjmp from the timer callback, so that read
or write would never be reached.



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

shm_open is an exception, sem_open and mq_open need file descriptors
which have to be usable in real-time context, so the registry needs to
be there. And the machinery for shared memory is also available, so
implementing the first way is simply usual skin work.

Besides, Linux shm_open creates a shared memory for user-space
applications. In order to use it for shared memory between kernel and
user spaces, we would have to rely on the internals of Linux, which may
change. The /dev/rtheap character device, on the other hand, defines a
handler called by Linux when a user-space application calls mmap, like
any driver having an mmap method. Since the nucleus has the control of
what memory is passed to Linux in that handler, this memory become
accessible from kernel space without no further trick.



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

Actually, I believe that it requires less effort, since the unix I/O
calls are already implemented in Linux and libc. But I understand that
if this feature is simply a by-product, there is no reason to spend to
much time on it.



-- 


					    Gilles Chanteperdrix.