linux-kernel - Re: [PATCH v7 1/3] Documentation: common clk API

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: <alpine.LFD.2.02.1203202233340.24151@xanadu.home>
Date:	Tue, 20 Mar 2012 23:15:48 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Paul Walmsley <paul@...an.com>
cc:	Sascha Hauer <s.hauer@...gutronix.de>,
	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Amit Kucheria <amit.kucheria@...aro.org>,
	linaro-dev@...ts.linaro.org,
	Linus Walleij <linus.walleij@...aro.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Saravana Kannan <skannan@...eaurora.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Mike Turquette <mturquette@...com>,
	Mike Turquette <mturquette@...aro.org>,
	Magnus Damm <magnus.damm@...il.com>,
	Deepak Saxena <dsaxena@...aro.org>, patches@...aro.org,
	Rob Herring <rob.herring@...xeda.com>,
	Russell King <linux@....linux.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Richard Zhao <richard.zhao@...aro.org>,
	Shawn Guo <shawn.guo@...escale.com>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 1/3] Documentation: common clk API

On Tue, 20 Mar 2012, Paul Walmsley wrote:

> We need to indicate in some way that the existing code and API is very 
> likely to change in ways that could involve quite a bit of work for 
> adopters.

[...]

> Anyway.  It is okay if we want to have some starter common clock framework 
> in mainline; this is why deferring the merge hasn't been proposed.  But 
> the point is that anyone who bases their code or platform on the common 
> clock framework needs to be aware that, to satisfy one of its major 
> use-cases, the behavior and/or API of the common clock code may need to 
> change significantly.

Paul,

While I understand your concern, please don't forget that the perfect is 
the enemy of the good.

This common clk API has been under development for over *two* years 
already, with several attempts to merge it.  And each previous merge 
attempt aborted because someone came along at the last minute to do 
exactly what you are doing i.e. underline all the flaws and call for a 
redesign.  This is becoming a bad joke.

We finally have something that the majority of reviewers are happy with 
and which should cover the majority of existing cases out there.  Let's 
give it a chance, shall we? Otherwise one might ask where were you 
during those development years if you claim that the behavior and/or API 
of the common clock code still need to change significantly?

> Explicitly stating this is not only simple courtesy to its users, many of 
> whom won't have been privy to its development.  It also is intended to 
> make the code easier to change once it reaches mainline.

The code will be easier to change once it is in mainline, simply due to 
the fact that you can also change all its users at once.  And it is well 
possible that most users won't have to deal with the same magnitude of 
complexity as yours, again reducing the scope for resistance to changes.

Let's see how things go with the current code and improve it 
incrementally.  Otherwise no one will get involved with this API which 
is almost just as bad as not having the code merged at all.

> So, until the API is well-defined and does all that it needs to do for its 
> major users, [...]

No, the API simply can't ever be well defined if people don't actually 
start using it to eventually refine it further.  Major users were 
converted to it, and in most cases The API does all that it needs to do 
already.  Otherwise you'll be stuck in a catch22 situation forever.

And APIs in the Linux kernel do change all the time.  There is no stable 
API in the kernel.  Extensions will come about eventually, and existing 
users (simple ones by definition if the current API already meets their 
needs) should be converted over easily.

Nicolas
--
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/