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 20:55:44 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Nicolas Pitre <nico@...xnic.net>
cc:	Arnd Bergmann <arnd@...db.de>, Kevin Hilman <khilman@...com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ingo Molnar <mingo@...e.hu>, david@...g.hm,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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, Nicolas Pitre wrote:

> On Thu, 31 Mar 2011, Thomas Gleixner wrote:
> 
> > Start off with such a trivial, but immense effective cleanup and see
> > what it helps to share code even accross SoC vendors. They all glue
> > together random IP blocks from the market and there are not soo many
> > sources which are relevant. This makes sense in all aspects:
> > 
> >       1) less and better code
> >       2) faster setup for new SoCs
> >       3) shared benefit for all vendors
> 
> If this was always true.  Someone commented on the fact that the IP 
> block providing USB on OMAP is shared with a couple other platforms.  
> But about 2600 lines of pure glue is still necessary around the common 
> driver to make it work for everyone.  I'm not saying that separate 
> drivers are called for here, simply that hardware people _will_ screw it 
> up, especially when they are hooking it up to a non-standard 
> SOC-specific bus.

Right. That's a problem, but we should not ignore the places where
reusing stuff is easy possible. And making good examples out of it.

And it really _IS_ worth the trouble. Look at the git log of
drivers/spi/pxa2xx* . We could have slapped the other "x86" driver
into spi, but that does not make any sense from a software engineering
and maintainability POV. And it would have been more work in the end
to cleanup the separate driver than isolating the existing one and
reuse it.

This is a sustainability issue. And we need to become more clever
about identifying the places where we can abstract stuff into shared
drivers and infrastructure when we want to sustain Linux for another
few decades.

> And what would the hardware guys tell you?  That software is cheap.

If you can prove with simple examples that using existing software
removes 6 month of useless reinventing the wheel and another 6 month
of testing plus the fight with the kernel folks, then eventually they
start to listen as you can express this in $$$.

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/