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

[Randy Dunlap]

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.

-- 
~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/