On 2013-05-19 10:24, Manuel Huber wrote: > Hello! > > I'm currently working on a patch for RTnet > (https://bitbucket.org/robinreal/rtnetts/overview exp branch) that > enables the user to retrieve time stamps from the driver (via > recvmsg). Currently development is not finished, there are still > bugs and I need to rewrite commit messages. Overview: > > * I hooked into the rt_udp_recvmsg function to optionally add time > stamps to the msghdr struct. The rt_socket_recv_timestamp function > is used to actually retrieve put the time stamp into the cmsg > buffer. This could maybe also be used for other protocols (?). > > * In stack/scm.c the original put_cmsg function has been ported to > RTDM. Currently I haven't yet implemented the put_cmsg_compat > function. > > * In rtnet_socket.h I added a member sk_flags, which could be used for > various other functions. This is used to activate and deactivate > passing time stamps to the user (through msghdr structure). > > * CONFIG_RTNET_SO_TIMESTAMPNS can be used to control whether RTnet > stack supports passing timestamps to user-space or not.
Still need to study this. Will have a look these days while traveling. > > > During implementation I ran into some problems: > > * 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... > > * 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. > > * Is it a good idea to support a similar interface as normal > SO_TIMESTAMPNS which requires to transform nanosecs_abs_t to a > timespec structure? To support this, I would have to evaluate a > division and a modulo operation of a 64bits variable and a 32bit > constant. I'm not sure whether this is a good idea or not. Currently > I'm thinking about inventing a new cmsg identifier and flag to just > copy the nanosecs variable and also support SO_TIMESTAMPNS (which > will introduce some extra latency when active). 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. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________ RTnet-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-developers
