Found the bug: a not closed port. Maybe other will run in this situation: My cleanup was done only when the socket handle was not 0. This seems to work with rtnet 0.2.x but now in 0.7.0 the first correct assigned socket handle is 0 :-Z
Sorry for having changed RTnet regarding this return value. However, this is a legal value according to POSIX, but normally 0 is the stdin file descriptor.
RTmac is loaded for kernelspace message sending - not for time slice
Sorry, what???
I used rt_sendmsg() to send configuration udp datagrams to the realtime NIC (without need for realtime behavior) from kernel space when a user wrote data to /proc interface on system startup. The mailing list told me that this was okay when rtmac is simply loaded (even without any further rtmac configuration) This seems NOT to work with 0.7.0, sendmsg_rt() called from kernel space always returns -38 (-ENOSYS?)
Is it correct, that this feature will not work from now because of internal rtnet changes? Only for confirmation - for other reasons I'm going to swap out sendmsg_rt() to an extra rttask.
I see. This hack actually worked with earlier versions. But now RTnet detects the caller's context and denies any call of /potentially/ blocking functions from non-real-time tasks.
If you don't want to setup a dedicated rt-task for sending your config messages now, take a look at the rtnet_rtpc subsystem of RTnet. It is intensively used to propagate commands issued by tools like rtcfg, rtping, or rtroute from the linux domain to a hard real-time context. And the API (include/rtnet_rtpc.h) is exported to any kernel module.
Jan
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
