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.
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
