netdev - Re: [PATCH 2/4] ptp/clcok:Introduce the setktime/getktime interfaces with "ktime

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]

Date:	Sat, 21 Mar 2015 02:16:41 +0100
From:	Arnd Bergmann <arnd@...aro.org>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	Baolin Wang <baolin.wang@...aro.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, John Stultz <john.stultz@...aro.com>,
	tglx@...utronix.de
Subject: Re: [PATCH 2/4] ptp/clcok:Introduce the setktime/getktime interfaces with "ktime_t" type

On Friday 20 March 2015, Richard Cochran wrote:
> Instead of changing to ktime_t, just use timespec64 instead.  That
> way, each change will be a couple of lines per file.

This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t. While both of the
current users require a timespec at the moment, it's possible that
there would one day be a third user that actually can make sense of
a ktime_t, and then we'd avoid the expensive back-and-forth conversion.

For now, using ktime_t in the interface merely simplifies the drivers
by moving the conversion into the subsystem, but it is not any more
or less efficient than the previous method.

> > I do agree however that we should merge the entire series at once so
> > we end up with a reasonable state afterwards, and we only need the conditional
> > in order to have a bisectable git history.
> 
> It is still bisectable with one or two patches.

Of course, but it would be rather bad style.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html