Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751293AbbEYT35 (ORCPT ); Mon, 25 May 2015 15:29:57 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:47652 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbbEYT3z (ORCPT ); Mon, 25 May 2015 15:29:55 -0400 X-Originating-IP: 50.43.43.179 Date: Mon, 25 May 2015 12:29:41 -0700 From: Josh Triplett To: James Bottomley Cc: "marcel@holtmann.org" , "clemens@ladisch.de" , "jslaby@suse.cz" , "rpurdie@rpsys.net" , "khalasa@piap.pl" , "linux-kernel@vger.kernel.org" , "jesper.nilsson@axis.com" , "3chas3@gmail.com" <3chas3@gmail.com>, "johan.hedberg@gmail.com" , "kaloz@openwrt.org" , "starvik@axis.com" , "tiwai@suse.de" , "j.anaszewski@samsung.com" , "pebolle@tiscali.nl" , "ohad@wizery.com" , "mcgrof@do-not-panic.com" , "gustavo@padovan.org" , "cooloney@gmail.com" , "gregkh@linuxfoundation.org" , "mcgrof@suse.com" , "mchehab@osg.samsung.com" , "bp@alien8.de" , "davem@davemloft.net" , "dmitry.torokhov@gmail.com" , "geert@linux-m68k.org" , "herbert@gondor.apana.org.au" , "arnd@arndb.de" , "airlied@linux.ie" Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses Message-ID: <20150525192941.GH1037@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432580834.2195.6.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: 1979 Lines: 38 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. 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. - 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/