linux-kernel - Re: [build failure] Re: [GIT PULL] sound updates for 2.6.39-rc1

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: <20110321163849.GF2570@opensource.wolfsonmicro.com>
Date:	Mon, 21 Mar 2011 16:38:49 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Takashi Iwai <tiwai@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jaroslav Kysela <perex@...ex.cz>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Zeng Zhaoming <b32542@...escale.com>
Subject: Re: [build failure] Re: [GIT PULL] sound updates for 2.6.39-rc1

On Mon, Mar 21, 2011 at 05:11:02PM +0100, Ingo Molnar wrote:
> * Mark Brown <broonie@...nsource.wolfsonmicro.com> wrote:

> > As indicated that's not a good fix since the affected code is all runtime 
> > conditional already. [...]

> Well, AFAICS Randy's patch correctly expresses current infrastructure 
> dependencies the driver has.

That's because the driver code is trivially broken, though - the build
test has identified a flaw in the driver which we should fix.

> SND_SOC_ALL_CODECS=y but !REGULATOR case, i.e. if it's desirable to have the 
> driver build more widely, then that can be enhanced further - but first please 
> If it's undesirable to disable the driver in the (unlikely but possible) 
> get things to build.

Right, and as I indicated in my reply Zeng said he'd fix this.  I'd
rather encourage vendors to take responsibility for their own drivers.

> > [...]  It'd be more likely to impede than help the sort of build coverage 
> > tests where one would encounter it.

> It's an invariant mostly - both Randy's and my testing will find breakages 
> regardless of how restrictively enabled this driver is.

My point is that this is the build test equivalent of using memset to
fix uninitialised variables, it's making the test pass rather than
making things work.  When fixing this sort of thing you need to at least
consider if the appropriate fix is to knock out the whole thing in
Kconfig or to make sure the code copes with the dependency set either
way.
--
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/