Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751365AbbEYVaS (ORCPT ); Mon, 25 May 2015 17:30:18 -0400 Received: from mx2.parallels.com ([199.115.105.18]:41364 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750859AbbEYVaP (ORCPT ); Mon, 25 May 2015 17:30:15 -0400 From: James Bottomley To: "josh@joshtriplett.org" CC: "rpurdie@rpsys.net" , "marcel@holtmann.org" , "linux-kernel@vger.kernel.org" , "clemens@ladisch.de" , "khalasa@piap.pl" , "3chas3@gmail.com" <3chas3@gmail.com>, "jesper.nilsson@axis.com" , "johan.hedberg@gmail.com" , "arnd@arndb.de" , "kaloz@openwrt.org" , "starvik@axis.com" , "tiwai@suse.de" , "j.anaszewski@samsung.com" , "pebolle@tiscali.nl" , "mcgrof@do-not-panic.com" , "ohad@wizery.com" , "gustavo@padovan.org" , "cooloney@gmail.com" , "gregkh@linuxfoundation.org" , "mcgrof@suse.com" , "jslaby@suse.cz" , "mchehab@osg.samsung.com" , "davem@davemloft.net" , "dmitry.torokhov@gmail.com" , "bp@alien8.de" , "geert@linux-m68k.org" , "herbert@gondor.apana.org.au" , "airlied@linux.ie" Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses Thread-Topic: [RFC v1] tree-wide: remove "select FW_LOADER" uses Thread-Index: AQHQlAdy+UmPanbaJUmvZ37dFChISp2HdkGAgACPIQCAAAT5AIAAEoIAgAAHWQCAAJafAIAAA+iAgAAGNgCAAAkkgIAAChcAgAAl64CABAHCgIAAdSKAgAAUUQCAAAZGgIAAIZQA Date: Mon, 25 May 2015 21:29:51 +0000 Message-ID: <1432589392.2195.11.camel@Odin.com> References: <20150522175711.GE40101@dtor-ws> <20150522181924.GN23057@wotan.suse.de> <20150522185207.GG40101@dtor-ws> <20150522192814.GO23057@wotan.suse.de> <20150522214357.GA24129@cloud> <1432551316.27695.166.camel@x220> <20150525175431.GD1037@x> <1432580834.2195.6.camel@Odin.com> <20150525192941.GH1037@x> In-Reply-To: <20150525192941.GH1037@x> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.149.214] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t4PLURNw007786 Content-Length: 2391 Lines: 44 On Mon, 2015-05-25 at 12:29 -0700, Josh Triplett wrote: > On Mon, May 25, 2015 at 07:07:14PM +0000, James Bottomley wrote: > > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote: > > > On Mon, May 25, 2015 at 12:55:17PM +0200, Paul Bolle wrote: > > > > On Fri, 2015-05-22 at 14:43 -0700, josh@joshtriplett.org wrote: > > > > > Ideally, someone should teach Kconfig to handle recursive dependencies, > > > > > > > > I'm probably reading too much in this remark, but how should it handle > > > > that other than returning an error because the configuration it's fed > > > > makes it run in circles? > > > > > > I don't mean cyclic dependencies (for which Kconfig should just report > > > an error, ideally including the full list of symbols forming the cycle). > > > > > > I mean that Kconfig should do recursive dependency resolution. If B > > > depends on A, and C depends on B, I should be able to turn on C > > > directly and have B and A enabled. > > > > That's really hard in practise you have to make any symbol that selects > > something depend on the dependencies of the selected symbol. You can't > > do this without involving a SAT solver. A guy promised to do this a > > couple of years ago, but the patches never materialised. However, they > > may exist somewhere if someone wants to take a look at completing it. > > You can't do this in the completely general case without a SAT solver. > However, I think it's possible to help the user a bit more than than > Kconfig currently does without introducing a general dependency solver. Well the logically simplest way of doing that it to require that a selected symbol can have no dependencies (but may select others) and to make this what Kconfig enforces ... of course, our current Kconfig tree violates this all over the place. > In particular, it'd be nice to have an easy way to see at a glance > "can't enable C because it depends on B", together with an easy way to > get to B to enable it to get to C. User-guided dependency resolution > seems like an improvement over no dependency resolution. Sure, but it's mostly people like us doing it and find . -name Kconfig\* -exec grep -3 {} /dev/null \; usually does the trick for me. James ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?