ok, I now understood where my error was. It was a mismatch between my old kernel headers and my new kernel that I am running !!!! Pretty stupid ! Tank's you for your time, you learn me some stuff, I appreciate it. Antoine 2007/11/13, Eric Dumazet <dada1@xxxxxxxxxxxxx>: > Antoine Zen-Ruffinen a écrit : > > THIS is what I did at the beginning. But is seem me to be some thing > > wrong. So I put a static value in skb->tstamp instead of > > ktime_get_real() for debug purpose. And I was still becoming the > > amount of second, microsecond since 1970. We are back to my initial > > mail ! The value of skb->tsamp doesn't seems to be returned by > > ioctl(). > > > OK Antoine. > > Yes, 'struct timeval' is as you discovered, ie relative to *something*, > a given event in the past. (in your case, CLOCK_REALTIME Epoch : January > 1th 1970) > > It is even documented (man gettimeofday) > > DESCRIPTION > The gettimeofday() function shall obtain the current time, > expressed as seconds and microseconds since the Epoch, and store it in the > timeval structure pointed to by tp. > > For timespec STAMPNS, see clock_gettime() description. > > clock_gettime(CLOCK_REALTIME, &ts); > > If in your driver you stick in tstamp.tv64 a value like 0x00010002, then > the result of ioctl(SIOCGSTAMP) will be : > tv.tv_sec = 0 (so yes, January 1th 1970) > tv.tv_usec = 65 (because 0x10002/1000 = 65) > > Not counting the fact that .tv64 should not be directly set, unless for > 0 value, because it is not portable. > > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
