Thread: Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

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

> On x86, the conversion will be barely visible. But on low-end archs, it
> may make a little difference. However, supporting a standard interface
> makes some sense to ease portability, so you should have SO_TIMESTAMPNS.
> An optimized interface could be added on demand.
I think it's best to support both interfaces, letting the user decide. 
For my task, the conversion is pointless, since I have to convert to 
nanosecs_abs_t again. It doesn't add a lot of complexity to the code to 
support both.

> First remark: You are mixing changes of different kind in your commits.
> Specifically changes to generated autotools are better kept separate
> from code changes (including changes to autotools input files). Same for
> coding style changes. That will ease the review later on. Fortunately,
> git allows you reorganize things as often as you like.
>
> Oh, and something is fairly broken in your tree over there. Looks like
> one commit deletes all the generated autotools files...
>
> BTW, I don't think this feature has to be optional at compile time. It
> only adds a single if to the hotpath, not really expensive. And you
> should really measure the difference between TIMESTAMPNS64 and
> TIMESTAMPNS.
Oh, sorry. I know, it's currently a mess. I plan to re-base exp and 
squash it to a single commit since actual code is just about 100 lines 
or so... I know that's not what you are supposed to do, but all 
intermediate commits don't add any value. The actual code isn't that 
complicated; As soon as I have figured out how it should be done. I used 
git to transfer between the PC I test on, and the PC I develop on, so 
the exp branch is really messed up...

I can remove CONFIG_RTNET_SO_TIMESTAMPNS, I just thought it's a good 
idea because the feature is new and it could cause problems (maybe on 
other architectures...), but of course, it decreases code readability.

I will try to keep different changes separate. I have recently checked 
another repository and it's really annoying, so thanks for the hint ;)

> What is your target arch?
My target is x86, but the patch should be available for all targets! 
Therefore I think it's best to leave the decision to the user...

Thanks for your help!

Thread: Re: [RTnet-developers] SO_TIMESTAMPNS for RTnet

rtnet-developers