Re: [PATCH] [RFC] time: Improve negative offset handling in timekeeping_inject_offset

From: Richard Cochran
Date: Tue Feb 25 2014 - 04:15:21 EST


On Fri, Feb 21, 2014 at 11:54:35PM +0100, Thomas Gleixner wrote:
> To be honest, it's not the prettiest thing, but timespec is not pretty
> to begin with.

yes...

> Sure our normalize function can cope with that, but where is the
> point?

and yes...

> Now if we allow that we also need to allow
>
> 5, -987654321
>
> versus
>
> 4, 12345679
>
> It's all unreadable in one way or the other.

and again yes...

> Aside of that, if we allow that for adjtimex, then how do we argue the
> restriction on all other timespec related interfaces?

(John already heard my opinion off list, but I would so much like to
state it again ;)

The timespec was already an ugly thing, even before we added the
ADJ_SETOFFSET. Our addition means that timespecs can also be negative
values, but no matter how you define it, someone will think another
way is more natural.

When implementing the clock shifting code in linuxptp, I simply followed
the existing "rule" that tv_nsec is non-negative, and so that program
just normalizes the timespec to make the kernel happy.

I think we should just leave the kernel/user interfaces as is because,

1. Applications can deal with the "rule" as is. It isn't hard. After
all, making the clock jump is an unusual thing to do in any case.
2. The "rule" is consistent with existing posix interfaces.
3. The kernel actually outputs timespecs in this way.

When I first looked at this from the user space POV, I took the
trouble to shift the clock back before 1970 in order to watch the
kernel timespecs counting down (or up?). Yes, it is weird, but the
nanoseconds field decreases as time goes forward.

[ You used to be able to do this before:
4e8b1452 "time: Improve sanity checking of timekeeping inputs" ]

My two Euro-Cents,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/