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 12:41:52 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	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>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [GIT PULL] omap changes for v2.6.39 merge window


* Russell King - ARM Linux <linux@....linux.org.uk> wrote:

> On Thu, Mar 31, 2011 at 10:06:34AM +0200, Ingo Molnar wrote:
> > Having strong, effective platform abstractions inside the kernel really helps 
> > even if the hardware space itself is inevitably fragmented: both powerpc and 
> > x86 has shown that. Until you realize and appreciate that you really have not 
> > understood the problem i think.
> 
> No, I think it is the other way around.  Folk like me and Nicolas over the 
> last ten years have put considerable amounts of effort into trying to keep 
> the ARM support code as clean and maintainable as possible.

Absolutely no argument about that, whenever i have read core ARM code it was 
always a pleasure. You guys are doing a fine job there.

What i argued with was what Nicolas said:

  > > > back in the early days of the PCs, different systems from different 
  > > > vendors had different bus types, peripherals at different addresses, 
  > > > etc. that didn't make all of those vendors systems different 
  > > > architectures, instead those things were varients of the x86 
  > > > architecture.
  > >
  > > Most of them didn't survive.  That really helps.

It does not matter whether hardware survives or not - most pieces of hardware 
do not survive. What matters is whether the inevitable hardware-churn is 
allowed to litter the kernel tree with unmaintainable pieces of crap.

You even mention that it's not maintainable to you:

> That is true of the common ARM stuff, but there's no way we can do this for 
> all SoC support - there aren't the hours in the day to provide such a wide 
> oversight. [...]

The problem is the solution:

> That's why we have SoC maintainers, and the SoC maintainers have the 
> responsibility to sort out their own sub-trees.

... which sets the wolves to mind the sheep, so to say. Self-oversight never 
worked very well (unless you believe in perpetual bank bailouts).

So Linus and Thomas (with the genirq hat on) are pushing back, because both of 
them feel affected negatively by crap.

"All is fine" or "it's just natural" do not seem like the right answers to 
those concerns.

Thanks,

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