Nadym Salem wrote: > On Wed, August 8, 2007 17:19, Jan Kiszka wrote: > >>> is there a way to find out with which kind of error rt_dev_close returns >>> ? >>> Linux close() sets the errno, checking errno after rt_dev_close returns >>> negative tells me "success". rt_dev_close returns with -524. >> Check > http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__userapi.html#ga34c1ddf4e2deb727a1ab3cd648ce5d9 > > I did check this site of course, but it only say > Returns: > 0 on success, otherwise a negative error code > errno does not seem to be set by the native close call, since it says > "success".
As the doc states: rt_dev_close returned the error directly, only the posix wrappers set errno. > But my negative error code does not help me in any way now. > rt_dev_close() fails and therefore I'm having trouble using the same > program more than once ;) Oops, sorry (RTFM - read the fine mail...). Indeed, -524 means -ENOTSUPP, and this error code is only returned in the asymmetric closure case. But that is actually broken in itself. Such a high error code should not leak into userland, and we would run better with returning -ENOSYS. That would trigger an automatic context switch internally. I think I'll kill that confusing warning in RTDM rev.6 already now. > >> vs. > http://www.xenomai.org/documentation/branches/v2.3.x/html/api/group__posix__shm.html#gafbcde67669a1b96577e735ddebd8634 > >>> I guess it has sth. to do with the note in rt_dev_close documentation. >>> The >>> open and socket call were made in a none xenomai context. I should leave >>> the context before closing, but don't really know how. >> Just avoid opening RTnet sockets in RT context (*), i.e. inside a shadow >> task in primary mode. Normally, this is no problem as, even if the >> caller is a shadow thread, there are Linux services executed before >> [rt_dev_]socket() so that you are still in secondary mode. > > the socket is created in non RT context. I'll try to switch manualy to > sec. mode before rt_dev_close() to see if that's the problem, but can't > really imagine. It is fairly likely the problem. Admittedly weird, and that's why I'm going to rework that code path. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
