linux-kernel - 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]

Message-Id: <201503201443.42672.arnd@linaro.org>
Date:	Fri, 20 Mar 2015 14:43:42 +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:
> On Fri, Mar 20, 2015 at 09:54:05AM +0800, Baolin Wang wrote:
> > Next patch series will contain all of the drivers which need to be changed.
> > But i think the conditional in ptp_clock.c can still in there.
> 
> Why?
> 
> > Because our plan is once all the drivers are converted, i will remove the
> > conditional, along with the original function pointer.
> > Is that OK? Thanks!
> 
> I want to avoid a patch series that introduces something, only to
> remove it later on.  Sometimes you have to do that way for a complex
> transformation, but this case is rather simple.
> 
> You can change the gettime signature in one patch, and the settime in
> a second patch.

We normally try to avoid doing those global API changes across many drivers
that are maintained by different people. Introducing the new API first
is the easiest way to get the per-driver patches reviewed individually
by the respective maintainers.

Doing gettime separately from settime would be rather silly here, so trying
to avoid the conditional would mean doing a single large patch across all
drivers.

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.

	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/