Philippe Gerum wrote:
... 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.
Would work, if all drivers that register against the RTDM layer support only primary mode handlers. But RTDM provides two entry points for every API call: RT/non-RT (i.e. primary/secondary+non-RT on fusion). And as RTDM has to mediate for all kind of drivers, not just RTnet's socket interface, it has to accept the calls from their current context.
This dual interface is typically of limited use for API functions like read/write/send/recv, but it is essential for open/socket/close/ioctl: non-RT entry allows non-RT resource allocation. On the other hand RT-handlers enable the driver developer to write specific handlers also for the time-critical case.
The tricky point is that the information in the syscall table is static, while driver registration is dynamic. Helpful would be to have some comparable function like pthread_migrate_rt from the fusion lib in the rtai lib => explicite mode switch, either performed by the driver in its non-rt handler or by the application after falling to secondary mode.
Ok, I've finally implemented both approaches, i.e. using the exec mode bits in the syscall table, or through rt_set_task_mode(). For the exec mode bit part, the new __xn_exec_conforming qualifier for syscalls should do what you need, i.e. it tells the nucleus to adapt the syscall context to the most conforming domain wrt to the current caller: IOW, it switches to primary if it's a fusion RT task, or remains into the Linux domain if it's a regular Linux task, before eventually branching to the syscall entry point.
rt_task_set_mode() now accepts a T_PRIMARY mode bit when called from user-space tasks, either in the setmask or clrmask argument. setmask |= T_PRIMARY switches the fusion task to primary mode, clrmask |= T_PRIMARY moves it to the secondary mode.
The patch below illustrates the use of the new conforming bit in a fusion syscall table:
--- ./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_conforming },
+ [_RTDM_SENDMSG] = { sys_rtdm_sendmsg, __xn_exec_conforming },
};--
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
