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

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.

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.

--
Eric Anholt
eric@xxxxxxxxxx eric.anholt@xxxxxxxxx


Attachment: signature.asc
Description: This is a digitally signed message part

Relevant Pages