Hi Arnd,

On 05/04/2015 12:14 PM, Arnd Bergmann wrote:

On Monday 04 May 2015 09:42:36 Hans Verkuil wrote:

quoted

Ping! (Added Arnd to the CC list)

Hi Hans,

sorry I missed this the first time

quoted

On 04/27/2015 09:40 AM, Hans Verkuil wrote:

quoted

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?

Thanks!

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).

Thanks!

	Hans