[RTnet-users] Re: userspace support for fusion

[Philippe G. <rp...@xe...>]

Hi Jan,

Jan Kiszka wrote:
> Hi,
> 
> RTnet just gained userspace support under RTAI/fusion (tested with 
> latest fusion-CVS), see the SVN. This is more a less a hack to the 
> existing RTDM port for fusion (no library, just ugly static-inlines), 
> but it is not intended to stay for long. On the mid-term, it is planned 
> to merge RTDM into the official fusion branch anyhow,

Confirmed here, FWIW.

> so this version 
> can be seen as a first (usable!) demonstration of the functionality.
> 
> I also ported two examples to fusion, namely the interface lister 
> rtnet_ifs and the ip-fragmentation example frag-ip. Both work smoothly, 
> and demonstrate the usage of RTnet in fusion userspace quite well (I 
> hope). There is one tricky point again, common to both classic and 
> fusion: automatic hard/soft respectively primary/secondary mode 
> switching of threads. See the hack I had to add to frag-ip in order to 
> switch back after printing some texts. RTnet's send/receive functions 
> always require hard/primary context to execute! This is an issue we have 
> to think about again when integrating RTDM into fusion.
> 

I'd suggest this to solve the issue:

--- ./rtnet/rtai_rtdm/rtdm.c~	2005-04-21 18:05:36.000000000 +0200
+++ ./rtnet/rtai_rtdm/rtdm.c	2005-04-21 18:20:03.000000000 +0200
@@ -966,8 +966,8 @@
      [_RTDM_IOCTL]   = { sys_rtdm_ioctl,   __xn_exec_current },
      [_RTDM_READ]    = { sys_rtdm_read,    __xn_exec_current },
      [_RTDM_WRITE]   = { sys_rtdm_write,   __xn_exec_current },
-    [_RTDM_RECVMSG] = { sys_rtdm_recvmsg, __xn_exec_current },
-    [_RTDM_SENDMSG] = { sys_rtdm_sendmsg, __xn_exec_current },
+    [_RTDM_RECVMSG] = { sys_rtdm_recvmsg, __xn_exec_primary },
+    [_RTDM_SENDMSG] = { sys_rtdm_sendmsg, __xn_exec_primary },
  };

This implies that callers must be fusion RT tasks in user-space like it 
seems reading the example. If not, i.e. would any Linux task be able to 
call these services into the RTAI domain, then using __xn_exec_histage 
instead would do.

> Furthermore, I was not able to trigger any hidden RTAI problems under 
> fusion - which is also a big step forward compared to the situation with 
> RTAI <= 3.1! I haven't recently tested 3.2 with RTnet, but most 
> scheduler issues seem to be fixed there as well the time I tried with 
> old magma. However, any new userspace projects on top of RTnet should 
> definitely try fusion first, it has further advantages (e.g. gdb support).
> 
> The SVN also include a patch by Fabian Koch to improve the selection 
> scheme when loading RT-NICs on system with multiple cards. This scheme 
> now works like this: When you have four NICs of the same type 
> (theoretical scenario, at least we do not have such a box yet :)), issue 
> "insmod <rt_driver> cards=0,1,0,1" to let the real-time NIC driver grab 
> only the second and the fourth one. This scheme now works for all 
> drivers except the broken ones (MPC drivers and the 3c59x).
> 
> There is another patch pending to add (upon request via configure 
> switch) IRQ-sharing support with normal Linux, I hope to merge it soon. 
> This might conflict with hard RT-requirements (therefore the configure 
> switch), but it was suggested by a user who wants to use RTnet in a 
> soft-RT scenario without being able to separate the RT-NICs IRQ from 
> some Linux IRQ.
> 
> Have fun!
> Jan

-- 

Philippe.