All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038@lists.linaro.org, Junghak Sung <jh1009.sung@samsung.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [Y2038] Which type to use for timestamps: u64 or s64?
Date: Thu, 5 Nov 2015 10:05:44 +0100	[thread overview]
Message-ID: <563B1BE8.8090007@xs4all.nl> (raw)
In-Reply-To: <10717379.s8aWAKUxAs@wuerfel>

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

  reply	other threads:[~2015-11-05  9:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-05  7:41 Which type to use for timestamps: u64 or s64? Hans Verkuil
2015-11-05  8:36 ` Arnd Bergmann
2015-11-05  9:05   ` Hans Verkuil [this message]
2015-11-05  9:25     ` [Y2038] " Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=563B1BE8.8090007@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=arnd@arndb.de \
    --cc=jh1009.sung@samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.