From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933243AbbDVS6L (ORCPT ); Wed, 22 Apr 2015 14:58:11 -0400 Received: from mx-rz-2.rrze.uni-erlangen.de ([131.188.11.21]:38847 "EHLO mx-rz-2.rrze.uni-erlangen.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932299AbbDVS46 (ORCPT ); Wed, 22 Apr 2015 14:56:58 -0400 X-RRZE-Submit-IP: 188.105.243.176 Message-ID: <5537EEF6.7020502@fau.de> Date: Wed, 22 Apr 2015 20:56:54 +0200 From: Andreas Ruprecht User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Denys Vlasenko , LKML CC: Stefan Hengelein , Paul Bolle Subject: Re: Abuse of CONFIG_FOO's as feature selectors References: <5537E665.3010800@redhat.com> In-Reply-To: <5537E665.3010800@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 22.04.2015 20:20, Denys Vlasenko wrote: > Hi, > > Kernel has a growing number of CONFIG items which are not > user-selectable features of their particular kernel builds, > but simply booleans controlled by other CONFIGs. > Example: > > I see how this practice originated: "select" statement > was initially added so that if feature X requires feature Y, > this can be enforced, but it was easy to use it to define > other booleans. > > I have a feeling that in retrospect, it was a mistake. > > It clutters .config with information which has nothing to do > with user's choice. > > More importantly, now when you read some code, you don't know > whether a CONFIG_FOO you look at is user's configuration choice > or something else. Well, there seems to be at least some convention with regards to the name of those options: They all start with (ARCH_)HAS/HAVE/MIGHT_HAVE and so forth. > > Now there are hundreds, maybe even thousands of these non-config > CONFIGs everywhere. > > > The same effect can be achieved, with marginally more typing, > with usual C defines in some header file: > > #ifdef CONFIG_X86 > # define ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS > # define ARCH_HAS_FAST_MULTIPLIER > # define ARCH_HAS_GCOV_PROFILE_ALL > # define ARCH_MIGHT_HAVE_PC_PARPORT > # define ARCH_MIGHT_HAVE_PC_SERIO > ... > > Maybe we should stop doing the former and use the latter method? Problem is, most of these options which are not selectable by the user operate as something like a "bridge" inside Kconfig itself. For example, an architecture can specify that it has some specific feature upon which a driver might depend. So, the architecture Kconfig file can set the option, the driver can *depend* on it, allowing the driver only to be built on the right architectures. Transferring everything into a header (quite like include/config/auto.conf works) would hence break the whole point of the "bridge" rationale behind it, as only the code (and not Kconfig) would be able to see this information. But I generally agree, the distinction between configuration options selectable by the user, options only present to model dependencies inside the guts of Kconfig and other things (like CONFIG_AS_AVX2, which is only passed as a compiler parameter from a Makefile, yuck) is not clear at all and can be quite confusing. Regards, Andreas P.S.: I've CCed some folks who might want to add their thoughts.