Jan Kiszka wrote:
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.
Having an "official" way to switch explicitly between the two modes under the rtai_native skin is very useful, thanks.
But the __xn_exec_conforming qualifier doesn't change much with respect to RTDM. RTDM could only apply this flag to entry points like sendmsg_rt in case it knew that ALL drivers behind the calls intend to provide exactly such semantic. Again, this is a dynamic decision made through device registration against RTDM, it cannot be figured out when RTDM registers its interface against the Xenomai nucleus.
However, I appreciate your quick effort, and there are certainly other scenarios than RTDM where the latter feature is helpful as well.
Jan
------------------------------------------------------- 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
