lkml.org 
[lkml]   [2009]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2009-02-05 18:21    [W:0.205 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site