Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

[Jan K. <jan...@we...>]

On 2013-06-13 18:28, Manuel Huber wrote:
> 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.

More precisely, msg_controllen and msg_flags are written back. I didn't
find an explicit statement in the POSIX spec that says the other fields
have to remain unchanged, but I guess there is code assuming this.

> 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?

I'm fine with changing the write-back logic at RTDM level. Send a patch,
and I will ack it for Xenomai.

Jan