From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758562AbZBETV1 (ORCPT ); Thu, 5 Feb 2009 14:21:27 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751562AbZBETVT (ORCPT ); Thu, 5 Feb 2009 14:21:19 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:44776 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbZBETVS (ORCPT ); Thu, 5 Feb 2009 14:21:18 -0500 Date: Thu, 5 Feb 2009 20:20:59 +0100 From: Ingo Molnar To: Randy Dunlap Cc: Eric Anholt , Linus Torvalds , Norbert Preining , "Rafael J. Wysocki" , Linux Kernel Mailing List , Jens Axboe , Hiroshi Shimamoto , samr Subject: Re: 2.6.29-rc3-git6: Reported regressions from 2.6.28 Message-ID: <20090205192059.GB27422@elte.hu> References: <20090204181109.GR21085@gamma.logic.tuwien.ac.at> <20090204185606.GA12991@elte.hu> <1233809147.13118.8.camel@gaiman> <498B1F2A.70209@oracle.com> <20090205191234.GG20470@elte.hu> <498B3A8F.3040801@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <498B3A8F.3040801@oracle.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Randy Dunlap wrote: > Ingo Molnar wrote: > > * Randy Dunlap wrote: > > > >> Eric Anholt wrote: > >>> On Wed, 2009-02-04 at 19:56 +0100, Ingo Molnar wrote: > >>>> * Linus Torvalds 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. ( 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. ) Ingo