Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

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

On 2013-06-03 12:06, Manuel Huber wrote:
>>> * I couldn't really find out, where the "normal" Linux Kernel fixes
>>>     the cmsg structure. After all messages have been added to the
>>>     buffer, the original start address and the resulting length has to
>>>     be written to the structure. I'm currently doing this in
>>>     rt_udp_recvmsg (just before "return") but I believe there is a
>>>     better place...
>> You could run the kernel against a debugger (kgdb or the built-in
>> gdbserver of QEMU/KVM) and set a watchpoint...
> Sounds interesting, I haven't used either of these two, but I should
> definitely set up QEMU! 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.
> 
> So maybe that's something that should be changed in Xenomai? Is
> sys_rtdm_recvmsg (ksrc/skins/rtdm/syscall.c) the function that is always
> called, no matter which skin is used? Or are there system call numbers
> defined for every skin? So if I use RTnet together with POSIX skin, and
> I'm using the recvmsg function, __wrap_recvmsg is called (compiler
> magic), which uses:
> 
>    set_errno(XENOMAI_SKINCALL3(__rtdm_muxid, __rtdm_recvmsg, fd -
>    __rtdm_fd_start, msg, flags));
> 
> which will actually resolve to a call to sys_rdtm_recvmsg?
> 

Yes. RTDM is a skin of its own, and even POSIX uses it to provide
send/recv services.

>>> I don't understand how to implement socket options. Is it okay to
>>> just introduce a new ioctl, or is it better to use setsockopt? I'm
>>> just unsure where to implement this. Currently I wrote some code to
>>> ip_sock.c in stack/ipv4 but that's wrong. It currently doesn't work
>>> because of the level... The Linux Kernel has got the file sock.c
>>> which implements a handler for SOL_SOCKET. Is there a simple method
>>> to use setsockopt, or is it better to just introduce a new ioctl?
>> You receive setsockopt request via an official IOCTL from the RTDM
>> layer. Watch out for _RTIOC_SETSOCKOPT.
> I'm not sure which function is supposed to handle this request. In
> Linux, for example, I believe sock_setsock... only handles requests on
> SOL_SOCKET level. I can't really figure out, how this is done on RTnet.
> It would require some changes to (for example) add SO_TIMESTAMPNS to
> rt_socket_common_ioctl: I would have to handle _RTIOC_SETSOCKOPT, and
> then filter SO_TIMESTAMPNS and if it's some other option or some other
> level, just return -EOPNOTSUPP?
> 
> What's the difference between rt_socket_if_ioctl and
> rt_socket_common_ioctl? It's a little complicated to figure out what
> exactly happens if ioctl is called (on a socket)... Maybe I will try
> again in a few days... I think I have to first check Xenomai, and then
> it may be obvious which function is called first... Most likely Xenomai
> will already call the function defined in some RTDM device structure,
> which will call rt_socket_if_ioctl and rt_socket_common_ioctl ...

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.

Jan