Messages in this thread | | | Date | Thu, 05 Feb 2009 09:17:30 -0800 | From | Randy Dunlap <> | Subject | Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28 |
| |
Eric Anholt wrote: > On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote: >> * Linus Torvalds <torvalds@linux-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.
> Believe me, I hate this inconvenience to users even more than each of > you do, because I get to deal with the reports. But I haven't had the > time to sit down and figure out what drugs kbuild is on, or even how to > work around it (despite IRC help from a few other kernel guys). > > The alternative I can see is to ifdef the code for something that will > be on by default and which stable userland will require in 6 months. > That seems wrong. >
-- ~Randy
| |