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@cosmosbay.com>:
quoted text
> 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 netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html