Hello!
Xenomai only dispatches the IOCTL syscall to the driver's IOCTL handler.
It does not interpret the request issued this way. What happens then can
easily be traced by following the handler in RTnet: IOCTLs on UDP
sockets, e.g., enter at rt_udp_ioctl. There you also find a use case of
rt_socket_common_ioctl.
Okay, I was a little confused, but I think I understood it now.
I'm not sure if the current implementation is okay, I'm still a little
confused with the levels (SOL_IP, SOL_SOCKET) and their relation
and purpose... I have just moved the control of the timestamping
to ipv4's /ioctl/ call which checks the level and either calls
rt_ip_setsockopt
or rt_socket_setsockopt (same for ...getsockopt).
I have also tried to fix my repository, but it's still not perfect I fear. I
was amazed how powerfull rebase and add -p are ;)
Intermediate commits won't really work. Shall I fix this as well or
reduce some more commits? The current state can be viewed at
https://bitbucket.org/robinreal/rtnetts/overview tmp_rebase_2 branch.
It's not finished yet, I plan to test everything once again on different
machines
but at least SCM_TIMESTAMPNS64 (the new timestamping mechanism) should
work.
But I think I have already figured out: it's on line 2166 and 2169 in
__sys_recvmsg (net/socket.c). The socket level recvmsg functions
operate on a copy in kernel space and the original user structure
doesn't get modified (therefore the original address is still
available in msg_control); the __put_user function just updates the
msg_controllen field.
What do you think about the different handling of struct msghdr in
regular linux
and RTDM? I believe the cmsg part should get fixed in RTDM instead of udp.c.
RTAI 3.5
Should there be a change in addons/rtdm/module.c the function
sys_rtdm_recvmsg in Line 116
Xenomai
Should there be a change in ksrc/skins/rtdm/syscall.c the function
sys_rtdm_recvmsg in Line 96
Or is it better (and less effort) to just pay attention to fix the cmsg
struct in udp_recvmsg as it's
currently done and maybe do that again if the feature should be
implemented for some other
protocol?
Best regards, Manuel
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
RTnet-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-developers
