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.
I see. The dynamic issue wins it all here; can't get through using the syscall's static context marker.
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, so, what about providing T_PRIMARY as an additional mode bit to rtai_task_set_mode() ? Setting T_PRIMARY would switch to primary, clearing it would switch to secondary. Actually, since rtai_task_set_mode() is marked as exec_primary, T_PRIMARY effect would basically be enforced on entry already, but well, you get the idea.
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
