linux-kernel - Re: [PATCH 0/2] Common struct clk implementation, v14

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:	Thu, 14 Apr 2011 09:39:58 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-sh@...r.kernel.org, Sascha Hauer <s.hauer@...gutronix.de>,
	Paul Mundt <lethal@...ux-sh.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Dima Zavin <dmitriyz@...gle.com>,
	Saravana Kannan <skannan@...eaurora.org>,
	Ben Dooks <ben-linux@...ff.org>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/2] Common struct clk implementation, v14

On Thu, 14 Apr 2011, Russell King - ARM Linux wrote:

> On Thu, Apr 14, 2011 at 07:59:58AM -0400, Nicolas Pitre wrote:
> > Quoting Linus:
> > 
> > | Umm. The whole "number of lines of code" thing has become a total red
> > | herring.
> > | 
> > | THAT IS NOT WHY I STARTED TO COMPLAIN!
> > | 
> > | The reason I point out the number of lines of code is because it's one
> > | of the more obvious _symptoms_ of the problem.
> > 
> > So we need to work on infrastructure, and the clock API is exactly that.  
> > Obviously adding it will increase the number of lines of code initially, 
> > but eventually this will help _reduce_ them, and more importantly it 
> > will allow for the reduction of mindless duplication of code that was 
> > identified as being the actual problem causing maintenance pain.
> 
> Adding it without anyone using it doesn't solve anything.  We need
> people to commit to producing patches to use it for the next merge
> window.

People are simply waiting for the API to hit some upstream tree (like 
yours) before committing to it.  You would be in a much better position 
if those patches are in your tree, so that you can tell people: "Here's 
the Git branch with the API in it, so now I'm expecting patches to 
convert clock users to it".

> And if you think its not about lines of code - grab the current linux-next
> tree and look at the diff between v2.6.39-rc1 and master for arch/arm, and
> then tell me whether using LOC is unreasonable given the patch content.

I might have a look later.  However it is clear that the ARM tree will 
_never_ be as small as, say, X86 or even PPC given the indisputable 
amount of hardware variations within the ARM landscape that is not to be 
seen anywhere else.  Until the ARM ecosystem converge towards a single 
whole-system architecture we won't be able to match X86 in terms of code 
reduction.  Anyone thinking otherwise is living in a different universe.

However we can and must do better in consolidation work in order to make 
the tree more maintainable of course.  _That_ is the real issue and 
_that_ is what the ARM tree sucks at.  The fact that this consolidation 
work might reduce the size of the ARM code is only a side effect, not 
the primary goal.  So let's not get too hung up about LOC but focus on 
improving the infrastructure instead.

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/