[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.0.999.0709061600250.3781@enigma.security.iitk.ac.in>
Date: Thu, 6 Sep 2007 16:04:28 +0530 (IST)
From: Satyam Sharma <satyam@...radead.org>
To: David Woodhouse <dwmw2@...radead.org>
cc: Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-mtd@...ts.infradead.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: [2/2] 2.6.23-rc5: known regressions with patches
On Thu, 6 Sep 2007, David Woodhouse wrote:
>
> This isn't really a regression -- it's been like this for years. It's a
> non-functional configuration which doesn't really make sense, and would
> only crop up with randconfig (or crack).
>
> Linus was offered the patch a few weeks ago, but didn't take it -- it's
> not really a priority for 2.6.23. It's in my git tree and will be pushed
> when the 2.6.24 merge window opens.
>
> http://git.infradead.org/?p=mtd-2.6.git;a=commitdiff;h=241651d04d672fb685b2874707016cbbf95931e5
You shouldn't push this even for 2.6.24 ... I can't see why/how a runtime
BUG() scores over erroring out at build-time itself. And if there is no
codepath that leads to that BUG() at runtime, then what's the point of
adding dead code ...
So I wonder if what you're actually looking for is some kind of Kconfig
dependencies that will *prevent* the kind of .config from being generated
that Ingo ran into ?
Satyam
-
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/
Powered by blists - more mailing lists