lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8039151.bl38b7tgr4@wuerfel>
Date:	Thu, 22 Oct 2015 15:17:20 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
Cc:	outreachy-kernel@...glegroups.com,
	Amitoj Kaur Chawla <amitoj1606@...il.com>,
	linux1394-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, y2038@...ts.linaro.org
Subject: Re: [PATCH v2] firewire: Replace timeval with timespec64

On Thursday 22 October 2015 15:07:50 Stefan Richter wrote:
> Looks fine to me, but I have a question.  It was possibly already
> discussed at patch v1, though that was apparently not posted to an open
> list.
> 
> include/linux/timekeeping.h says:
> #define ktime_get_real_ts64(ts) getnstimeofday64(ts)
> 
> kernel/time/timekeeping.c says:
> /**
>   * do_gettimeofday - Returns the time of day in a timeval
>   * @tv:         pointer to the timeval to be set
>   *
>   * NOTE: Users should be converted to using getnstimeofday()
>   */
> 
> So what is the reason for calling ktime_get_real_ts64() instead of
> getnstimeofday[64]()?

They are identical in behavior, I don't know exactly why we have two
but I'm advocating the move to ktime_* functions for consistency
with ktime_get_seconds(), ktime_get_ns() and ktime_get() that don't
have another alias. Once all users of the old getnstimeofday()
and do_gettimeofday() have been converted, I might change over all
users of getnstimeofday64() to ktime_get_real_ts64() and remove
all of the get*timeofday*() family.
 
> PS, note to self:
> Independently of this patch, I need to check whether CLOCK_REALTIME was
> really the right clock here, in contrast to CLOCK_MONOTONIC.

Yes, good idea. I usually recommend changing to montonic time
(ktime_get_ts64()) in the same patch, but in this particular case that
would have been a user-visible change that we should not mix in
to a single commit.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ