Common Driver Model for RTAI

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
>  > ...
> 
>>> What is the advantage of
>>> having a real function like rt_timer_read just calling xnpod_get_time 
>>> *in the kernel*? Practically, there is no such thing like binary 
>>> compatibility for kernel modules, you better recompile in this 
>>> domain. Therefore, changes to the internal implementation will not 
>>> remain unnoticed to drivers. Actually, this question actually touches 
>>> the kernel side of the native skin beyond the RTDM aspect.
>>>
>>> For each RTDM driver API function we should carefully analyse what 
>>> additional value the native skin implementation can provide us. And 
>>> what the total costs are when we have to load a stripped-down 
>>> rtai_native AND to link against librtai just for RTDM usage.
>>>
>>
>> Agreed. In any case, fusion is API-agnostic, and RTDM could also use 
>> the core thread and synchronization object abstractions exported by 
>> the nucleus. In such a case, the option to have it as a skin on its 
>> own would likely be better than the inclusion in the native skin I've 
>> suggested.
>>
> 
> I think we will have a start with implementing a bit in this direction 
> while keeping an eye on the amount of that is similar to the native skin.
> 
>>> ...
>>> Then you would vote for identical names of the upper interface across 
>>> all skins?
>>
>>
>> Yes, clearly. Additionally, I would also vote for reusing the regular 
>> open/read/write/ioctl/close and route them properly to either the RTDM 
>> skin or the standard glibc services. It would be quite easy to do so 
>> using link stage wrappers from a librtdm.so library, and some sort of 
>> simple daisy chain, i.e.
>>
>> int __wrap_open (const char *pathname, int flags, mode_t mode)
>> {
>>      /* Granted we never "create" RT devices, we would gently
>>         ask first RTDM to check whether "pathname" belongs to 
>> its              namespace and open it, or return -ENOCOMPRENDO if it
>>         can't open that sort of things. */
>>     
>>     int err = XENOMAI_SKINCALL2(rtdm_muxid,
>>                 pathname,
>>                 flags);
>>
>>     if (err == -ENOCOMPRENDO)
>>         /* Maybe the Linux kernel knows better. */
>>         return __real_open(pathname,flags,mode);
>>
>>     return err;
>> }
>>
> 
> This would work...
> 
>> The same goes with read/write and friends, just passing the fildes to 
>> the RTDM skin so that it could check whether we are talking to one of 
>> its devices.
>>
> 
> ...but this likely not. You only have to consider a scenario where two 
> file handles returned by RTDM and those provided by Linux+glibc are 
> identical. Now, how to address the non-rt device this way? The wrapper 
> call will always pick the rt-variant first. I think we will not be able 
> to define some automatic demultiplexing mechanism for RTDM handles, this 
> will likely only work explicitly.
> 
> One may have the idea to play with the handle value returned by either 
> RTDM or Linux. Well, we already tried this with RTnet. Once we had a few 
> high-order bits of the file handle used as instance counter. As RTDM has 
> no per-process name space for its handles but rather maintains a global 
> list, the idea was to increment those instance counter right after 
> close() in order to avoid that buggy programs continue to work against 
> already closed handles that were meanwhile reused for other programs. 
> But then we started thinking about select/poll and noticed that there 
> are standard macros involved to create file descriptor sets, and those 
> macros assume that file descriptors are rather small integer values.

Why just not reserving the fildes at Linux level, instead of having RTDM 
decide for it, like this:

int __wrap_open (const char *pathname, int flags, mode_t mode)
{
	int rfd;

	rfd = open("/dev/null",flags);

       /* Granted we never "create" RT devices, we would gently
         ask first RTDM to check whether "pathname" belongs to
	its namespace and open it, or return -ENOCOMPRENDO if it
          can't open that sort of things. */

      int err = XENOMAI_SKINCALL3(rtdm_muxid,
                  pathname,
                  flags,
		 rfd);

      if (err == -ENOCOMPRENDO) {
	close(rfd);
          /* Maybe the Linux kernel knows better. */
          return __real_open(pathname,flags,mode);
	}

      return err ?: rfd;
}

In this scenario, RTDM would just have to update its own internal 
reservation bitmap to track valid fildes as the user-space feeds it, 
with the additional advantage of being constrained to FD_SETSIZE. A way 
should be found to track auto-closures upon process exit, but here, 
fusion can help with the proper callbacks.

-- 

Philippe.