linux-kernel - Re: [GIT PULL] omap changes for v2.6.39 merge window

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, 31 Mar 2011 17:01:40 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Kevin Hilman <khilman@...com>
cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>, Nicolas Pitre <nico@...xnic.net>,
	david@...g.hm, Linus Torvalds <torvalds@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Tony Lindgren <tony@...mide.com>,
	David Brown <davidb@...eaurora.org>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-omap@...r.kernel.org,
	Catalin Marinas <catalin.marinas@....com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window

On Thu, 31 Mar 2011, Kevin Hilman wrote:

> Thomas Gleixner <tglx@...utronix.de> writes:
> 
> > But the current SoC maintainer model does not work either. The SoC
> > maintainers care about their sandbox and have exactly zero incentive
> > to look at the overall picture, e.g reuse of code for the same IP
> > blocks, better abstraction mechanisms etc. 
> 
> zero incentive?  that's a bit strong, IMO.
> 
> That may be true for some SoCs, it's not really fair as a sweeping
> statement.

Fair enough, but it's the perception in general.

> Conference (ELC, US and Europe.)  Especially as IP blocks are reused
> across SoC families, abstractions like runtime PM are the only way to
> keep the SoC specifics of PM out of the common driver.

Right, I know that these things happen, but at the same time the sheer
amount of stuff flowing in makes it hard that these infrastructure
stuff really works out. And we are only at the beginning of the big
shuffle "code in to mainline" game.

After cleaning up the whole irq stuff across the tree I can tell you,
that the mess is non-linear growing with the number of instances.

You can see the patterns which are:
    - copy and paste
    - introduce different bugs
    - add more abuse

That's what I'm really concerned about.

> Yes, ARM SoC maintainers have to make up some ground.  But compare this
> to just a couple years ago where the common complaint was "why aren't
> embedded SoC people contributing code to mainline", and you'll see we
> have come a long way.

Well, code comes in, which is progress. But we need to figure out how
to deal with the increasingly growing flood before we drown in it.

Thanks,

	tglx

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