Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751289AbbEZAru (ORCPT ); Mon, 25 May 2015 20:47:50 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:56518 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750949AbbEZArr (ORCPT ); Mon, 25 May 2015 20:47:47 -0400 X-Originating-IP: 50.43.43.179 Date: Mon, 25 May 2015 17:47:31 -0700 From: Josh Triplett To: James Bottomley 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 Message-ID: <20150526004731.GB3965@x> 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> <1432589392.2195.11.camel@Odin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432589392.2195.11.camel@Odin.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2887 Lines: 54 On Mon, May 25, 2015 at 09:29:51PM +0000, James Bottomley wrote: > 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. Or enforce that it has no disabled dependencies. > > 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. That's not particularly convenient from the middle of menuconfig when configuring a kernel. It'd be nice to be able to navigate in one step from a symbol to its dependencies within the menuconfig interface. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/