Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Ingo Molnar <mingo@xxxxxxx>
- Date: Thu, 5 Feb 2009 20:20:59 +0100
* Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote:
Ingo Molnar wrote:
* Randy Dunlap <randy.dunlap@xxxxxxxxxx> wrote:
Eric Anholt wrote:
On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:I tried what you had described in that email (from 2 weeks ago), got the
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:I tried select FB. It's the right thing to do. It doesn't work. I
On Wed, 4 Feb 2009, Norbert Preining wrote:if you mean that as a general principle, there's four very real downsides in
The problem is that if you have a configuration under 2.6.28 withoutSure. It's inconvenient, no question about that. I asked the i915 people
CONFIG_FB and just call make oldconfig, or even make config and don't
know that you loose the DRM. And I was using make oldconfig (there is a
graphical config?? ;-))
to look into not requiring CONFIG_FB, and I hope they will, but my point
is that I don't think we can consider "small one-time inconvenience" to be
a "regression".
my opinion.
Firstly, we could have done better (and still can do better), via various
easy and non-intrusive measures:
- We could add a runtime warning:
for example a WARN_ONCE("please enable CONFIG_DRM_I915 and CONFIG_FB")
that there's no DRM because CONFIG_FB is not selected and oldconfig
loses the I915 setting silently - placed in a key DRM ioctl, would
have gone a long way addressing the issue. Testers do notice kernel
warnings that pop up when their X gets slow. (This approach might also
have the added bonus of warning folks who enable the wrong driver for
the hardware.)
- Or we could add a more thoughtful Kconfig migration:
Rename DRM_I915 to DRM_I915_FB [which it really is now], and keep
DRM_I915 as a non-interactive migration helper: if set, it
auto-selects both FB and DRM_I915_FB.
While CONFIG_FB is an interactive Kconfig option so a select can be
dangerous to a correct dependency tree, it seems safe to do in this
specific case because it seems to be a rather leaf entry with no
dependencies.
posted to the mailing list two weeks ago about the insane dependency
chain that kbuild comes up with and fails on when we do this, and got
silence.
same results that you did, but kbuild does seem very confused (to me).
reference email from 2+ weeks ago:
http://marc.info/?l=linux-kernel&m=123197341316461&w=2
Adding Sam to cc.
Check the patch i posted in this thread earlier today, it solves this
problem.
I saw it. I'd rather kconfig be fixed instead, if possible.
kconfig was not broken at all in this case. It detected a circular
dependency and did its work well.
( kconfig is broken in some areas - for example its misfeature of not
propagating selects along dependency chains is annoying. It should at
minimum warn when it sees such partial selects. But this is not one of
those breakages. )
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Randy Dunlap
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- References:
- 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Rafael J. Wysocki
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Linus Torvalds
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Norbert Preining
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Linus Torvalds
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Ingo Molnar
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Eric Anholt
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Randy Dunlap
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Ingo Molnar
- Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- From: Randy Dunlap
- 2.6.29-rc3-git6: Reported regressions from 2.6.28
- Prev by Date: Re: [git pull -tip] headers_check fixes for other architectures
- Next by Date: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- Previous by thread: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- Next by thread: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
- Index(es):
Relevant Pages
|