Hi Arnd,
We're redesigning the timestamp handling in the video4linux subsystem moving away from struct timeval to a single timestamp in ns (what ktime_get_ns() gives us). But I was wondering: ktime_get_ns() gives a s64, so should we use s64 as well as the timestamp type we'll eventually be returning to the user, or should we use u64?
The current patch series we made uses a u64, but I am now beginning to doubt that decision.
Regards,
Hans
On Thursday 05 November 2015 08:41:11 Hans Verkuil wrote:
Hi Arnd,
We're redesigning the timestamp handling in the video4linux subsystem moving away from struct timeval to a single timestamp in ns (what ktime_get_ns() gives us). But I was wondering: ktime_get_ns() gives a s64, so should we use s64 as well as the timestamp type we'll eventually be returning to the user, or should we use u64?
The current patch series we made uses a u64, but I am now beginning to doubt that decision.
I would lean towards u64, but I don't think it really matters either way, especially since all the drivers should be using monotonic timestamps now.
Arnd
On 11/05/15 09:36, Arnd Bergmann wrote:
On Thursday 05 November 2015 08:41:11 Hans Verkuil wrote:
Hi Arnd,
We're redesigning the timestamp handling in the video4linux subsystem moving away from struct timeval to a single timestamp in ns (what ktime_get_ns() gives us). But I was wondering: ktime_get_ns() gives a s64, so should we use s64 as well as the timestamp type we'll eventually be returning to the user, or should we use u64?
The current patch series we made uses a u64, but I am now beginning to doubt that decision.
I would lean towards u64, but I don't think it really matters either way, especially since all the drivers should be using monotonic timestamps now.
One thing that might be easier if it is a s64 is when adding/subtracting offsets from the timestamp. And the other reason is that a u64 gives a false view of the underlying type. With a s64 it is clear that a timestamp will wrap around after 292 years instead of double that. Admittedly, not our problem, but if we ever send a space probe to Alpha Centauri, then it might be nice to know as application developer that you need to take special measures if the mission takes longer than 292 years :-)
Regards,
Hans
On Thursday 05 November 2015 10:05:44 Hans Verkuil wrote:
On 11/05/15 09:36, Arnd Bergmann wrote:
On Thursday 05 November 2015 08:41:11 Hans Verkuil wrote:
Hi Arnd,
We're redesigning the timestamp handling in the video4linux subsystem moving away from struct timeval to a single timestamp in ns (what ktime_get_ns() gives us). But I was wondering: ktime_get_ns() gives a s64, so should we use s64 as well as the timestamp type we'll eventually be returning to the user, or should we use u64?
The current patch series we made uses a u64, but I am now beginning to doubt that decision.
I would lean towards u64, but I don't think it really matters either way, especially since all the drivers should be using monotonic timestamps now.
One thing that might be easier if it is a s64 is when adding/subtracting offsets from the timestamp. And the other reason is that a u64 gives a false view of the underlying type. With a s64 it is clear that a timestamp will wrap around after 292 years instead of double that. Admittedly, not our problem, but if we ever send a space probe to Alpha Centauri, then it might be nice to know as application developer that you need to take special measures if the mission takes longer than 292 years
There is another problem here if you are worried about the overflow: Unsigned overflow is well-defined in C, i.e. (U64_MAX + 1) is known to be 0. However, signed overflow is not defined in C for historic reasons, so taking the result of (S64_MAX + 1) can have arbitrary results [1], including a kernel oops, or random other things not related to the variable that carries the result, if gcc decides that 'this cannot happen'.
Arnd
[1] http://stackoverflow.com/questions/3948479/integer-overflow-and-undefined-be...
-
Arnd Bergmann -
Hans Verkuil