Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28

From: Randy Dunlap
Date: Thu Feb 05 2009 - 14:24:33 EST


Ingo Molnar wrote:
> * 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:
>>>>>> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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
--
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/