Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

[Manuel H. <man...@gm...>]

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