Messages in this thread | | | Date | Tue, 28 Dec 2010 13:53:32 +0100 | From | Richard Cochran <> | Subject | Re: [PATCH 0/3] Cleanup ADJ_SETOFFSET patch |
| |
On Tue, Dec 28, 2010 at 12:20:00PM +0100, Richard Cochran wrote: > The exisiting code seems to assume that a timespec can only have the > sign in one field. In other words, if tv_sec is non-zero, then tv_nsec > must be non-negative. (I added a check for this into my patch).
Looking at ktime.h we find:
* Be especially aware that negative values are represented in a way * that the tv.sec field is negative and the tv.nsec field is greater * or equal to zero but less than nanoseconds per second. This is the * same representation which is used by timespecs. * * tv.sec < 0 and 0 >= tv.nsec < NSEC_PER_SEC
So it seems that the time values (or time intervals) in the range -1 < x < 0 are not even possible, from the point of view of ktime.
> So it seems that I have now way to correctly encode a negative offset
I meant, "no way"---------^
> less than -1.0 into a timespec. Perhaps we could specify new rules for > timespecs.
> 1. Time Values: > If tv_sec is non-zero, then tv_nsec must be non-negative. > > 2. Time Deltas: > The sign of tv_sec and tv_nsec must be the same.
For me, the confusion gets worse when you consider the timespec values delivered by the system for dates before the 1970 epoch. In that case, the kernel always gives the tv_nsec value as a positive number. The value makes sense when interpreted as a sum.
Reading consecutive clock values every 0.1 seconds produces, for example:
{sec, nsec} sum ------------------------- {-2, +600000000} -1.4 {-2, +700000000} -1.3 {-2, +800000000} -1.2 {-2, +900000000} -1.1 {-1, 000000000} -1.0 {-1, +100000000} -0.9 {-1, +200000000} -0.8 {-1, +300000000} -0.7
If we say that the time value or interval in a timespec is always the sum of the fields, still it would seem that the ktime code is broken according to that assumption.
Perhaps someone can clarify?
Thanks, Richard
| |