Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751364AbbEYTHK (ORCPT ); Mon, 25 May 2015 15:07:10 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:35770 "EHLO relay5-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751182AbbEYTHH (ORCPT ); Mon, 25 May 2015 15:07:07 -0400 X-Originating-IP: 50.43.43.179 Date: Mon, 25 May 2015 12:06:47 -0700 From: Josh Triplett To: Paul Bolle Cc: "Luis R. Rodriguez" , Dmitry Torokhov , Takashi Iwai , Geert Uytterhoeven , Borislav Petkov , Greg KH , "David S. Miller" , clemens@ladisch.de, JBottomley@odin.com, David Airlie , Mauro Carvalho Chehab , Herbert Xu , Marcel Holtmann , "Gustavo F. Padovan" , Johan Hedberg , Mikael Starvik , Jesper Nilsson , Imre Kaloz , khalasa@piap.pl, Ohad Ben-Cohen , Arnd Bergmann , 3chas3@gmail.com, Jiri Slaby , Bryan Wu , Richard Purdie , Jacek Anaszewski , mcgrof@do-not-panic.com, "linux-kernel@vger.kernel.org" Subject: Re: [RFC v1] tree-wide: remove "select FW_LOADER" uses Message-ID: <20150525190647.GG1037@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> <1432578335.27695.186.camel@x220> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432578335.27695.186.camel@x220> 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: 3343 Lines: 72 On Mon, May 25, 2015 at 08:25:35PM +0200, Paul Bolle wrote: > On Mon, 2015-05-25 at 10:54 -0700, Josh Triplett wrote: > > 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. > > (My English might be letting me down here. Or my grasp of elementary > logic, for that matter. Recursive and cyclic are not really > interchangeable? Should Kconfig perhaps report a "Cyclic dependency > error"? ) I do think that'd be a clearer message, yes. For clarity: "recursive dependency resolution" as in "recursive resolution of dependencies", not "resolution of recursive dependencies". > > 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. > > And how should kconfig handle, say: > - B depends on (A || D) > - C depends on B > > Should (B && D) be enabled or (B && A)? This is not meant as a > rhetorical question. But I do fear the complications for the choices > this idea might encounter are, at best, not worth the effort. That's exactly the kind of problem that makes this difficult to do, and has thus stopped anyone from working on it. A fully general solution requires a system that can also solve arbitrary logic problems, which is not necessarily a feature. The typical choice made by package management systems is to enable B and A, preferring the leftmost dependency of B. That's what Debian's apt does, in the absence of conflicts. For an initial solution, I'd suggest just recursing through "select" dependencies; if C has "select B", and B has "select A", enabling C should enable B and A. Since you can't "select A || D", that seems straightforward enough. You can "select A if X", but for that, just bail out if the value of the expression X is changed by any of the select statements. > > As an intermediate measure, it'd be *really* handy to be able to browse > > in the curses UI directly from a symbol to the symbols it depends on to > > quickly enable/disable them, rather than having to look at the list of > > dependencies of a symbol, search for that symbol, remember the path the > > search showed, and browse there manually. > > Probably. I'd rather not think about the UI involved when the symbol(s) > that should be enabled is (are) two or more levels down the chain. And > the odd "stacked" UI for searches in the curses tool adds to the fun. > But then again, I'm a the-glass-is-half-empty person. I'm more thinking that if you're looking at an option, you should be able to hit a key to see all the symbols that option depends on in a list, then navigate to one of those symbols, and be taken to the menu containing that symbol with the cursor on that symbol. (You could then hit a key to go "back" to where you were.) It's not perfect, but it's an improvement. I'd also suggest that the search mechanism should produce a list that can be browsed with the arrow keys, with enter taking you to the symbol. - 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/