Messages in this thread | | | Date | Thu, 05 Feb 2009 11:23:36 -0800 | From | Randy Dunlap <> | Subject | Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28 |
| |
Ingo Molnar wrote: > * Randy Dunlap <randy.dunlap@oracle.com> wrote: > >> Ingo Molnar wrote: >>> * Randy Dunlap <randy.dunlap@oracle.com> wrote: >>> >>>> 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. >>> 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.
Maybe. I haven't seen an explanation for the problems that Eric reported 2+ weeks ago.
> ( 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. )
-- ~Randy
| |