[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090205191234.GG20470@elte.hu>
Date: Thu, 5 Feb 2009 20:12:34 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Randy Dunlap <randy.dunlap@...cle.com>
Cc: Eric Anholt <eric@...olt.net>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Norbert Preining <preining@...ic.at>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jens Axboe <jens.axboe@...cle.com>,
Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>,
samr <sam@...nborg.org>
Subject: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28
* Randy Dunlap <randy.dunlap@...cle.com> wrote:
> Eric Anholt wrote:
> > On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote:
> >> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >>
> >>> On Wed, 4 Feb 2009, Norbert Preining wrote:
> >>>> The problem is that if you have a configuration under 2.6.28 without
> >>>> 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?? ;-))
> >>> Sure. It's inconvenient, no question about that. I asked the i915 people
> >>> 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".
> >> if you mean that as a general principle, there's four very real downsides in
> >> 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.
> >
> > I tried select FB. It's the right thing to do. It doesn't work. I
> > 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.
>
> I tried what you had described in that email (from 2 weeks ago), got the
> 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.
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/
Powered by blists - more mailing lists