On 05/04/2015 12:14 PM, Arnd Bergmann wrote:
On Monday 04 May 2015 09:42:36 Hans Verkuil wrote:
Ping! (Added Arnd to the CC list)
sorry I missed this the first time
On 04/27/2015 09:40 AM, Hans Verkuil wrote:
Added the y2038 mailinglist since I would like to get their input for this API.
Y2038 experts, can you take a look at my comment in the code below?
Arnd, I just saw your patch series adding struct __kernel_timespec to uapi/linux/time.h. I get the feeling that it might take a few kernel cycles before we have a timespec64 available in userspace. Based on that I think this CEC API should drop the timestamps for now and wait until timespec64 becomes available before adding it.
The timestamps are a nice-to-have, but not critical. So adding it later shouldn't be a problem. What is your opinion?
It will take a little while for the patches to make it in, I would guess 4.3 at the earliest. Using your own struct works just as well and would be less ambiguous.
However, for timestamps, I would recommend not using timespec anyway. Instead, just use a single 64-bit nanosecond value from ktime_get_ns() (or ktime_get_boot_ns() if you need a time that keeps ticking across suspend). This is more efficient to get and simpler to use as long as you don't need to convert from nanosecond to timespec.
Possibly stupid follow-up question:
is ktime_get_ns() just a different representation as ktime_get_ts64()?
Or is there some offset between the two? They seem to be identical based on a quick test, but I'd like to be certain that that's always the case.
Users need to be able to relate this timestamp to a struct timespec as returned by V4L2 (and others).