Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757595AbbEVWWK (ORCPT ); Fri, 22 May 2015 18:22:10 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33367 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757344AbbEVWWG (ORCPT ); Fri, 22 May 2015 18:22:06 -0400 Date: Sat, 23 May 2015 00:22:00 +0200 From: "Luis R. Rodriguez" To: josh@joshtriplett.org Cc: Dmitry Torokhov , Takashi Iwai , Paul Bolle , 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: <20150522222200.GP23057@wotan.suse.de> References: <20150522065346.GA23022@pd.tnic> <1432282668.27695.24.camel@x220> <20150522175711.GE40101@dtor-ws> <20150522181924.GN23057@wotan.suse.de> <20150522185207.GG40101@dtor-ws> <20150522192814.GO23057@wotan.suse.de> <20150522214357.GA24129@cloud> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150522214357.GA24129@cloud> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2641 Lines: 62 On Fri, May 22, 2015 at 02:43:57PM -0700, josh@joshtriplett.org wrote: > On Fri, May 22, 2015 at 09:28:14PM +0200, Luis R. Rodriguez wrote: > > So the question still stands -- are there any kconfig options which > > depend on EXPERT which enable folks to screw up run time (not just driver > > tweaks? > > I don't think it should be possible OK, thanks! > > So unless I'm missing a corner case, it would seem replacing "select FW_LOADER" > > with "depends on FW_LOADER" is a reasonable option so far. The subtleties lie > > then now in since EXPERT is used by most distributions, everyone is an expert, > > and: > > > > a) Do we want to be consistent about ensuring run time sanity of EXPERT? > > b) Should we split EXPERT into tweak / possible run time break options? > > "depends on FW_LOADER" and "select FW_LOADER" are equivalent from the > point of view of what configs they allow; they differ in how the > dependency is shown in UIs. > > However, from the sounds of things, you want to add a dependency to > FW_LOADER. Nope the recursive case was that a new component which depends on FW_LOADER ended up selecting CRYPTO, and it turns out another driver which depends on FW_LOADER also depended on CRYPTO so that in turn creates a recursive dependency. > So in that case, yeah, switch to depends rather than > rewriting Kconfig, unless you're feeling really ambitious. OK so switching to "depends on" is the winning contender so far. > > > > Note that not changing this means we *will* eventually run into the > > > > recursive dependency issue later, either with my FW API change patches > > > > or some other future feature. Likewise for any other kconfig option > > > > with similar semantics. > > By "recursive dependency issue", I'm guessing that someone wants to make > FW_LOADER depend on something else, which breaks because "select" > doesn't know how to recurse? Kind of, the issue actually was a new component which depends on FW_LOADER and has crypto dependencies. Since the qat crypto driver selects FW_LOADER but also has a set of crypto dependencies that creates a recursive dependency loop. > Ideally, someone should teach Kconfig to handle recursive dependencies, > but in the meantime using "depends" makes sense. Doesn't sound like anyone is that enthusiastic about that. So... shall we just switch to "depends on" tree-wide then for FW_LOADER? Luis -- 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/