From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030809AbbDWT2L (ORCPT ); Thu, 23 Apr 2015 15:28:11 -0400 Received: from lb3-smtp-cloud2.xs4all.net ([194.109.24.29]:50694 "EHLO lb3-smtp-cloud2.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030357AbbDWT2I (ORCPT ); Thu, 23 Apr 2015 15:28:08 -0400 Message-ID: <1429817283.2927.35.camel@x220> Subject: Re: Abuse of CONFIG_FOO's as feature selectors From: Paul Bolle To: Denys Vlasenko Cc: Andreas Ruprecht , Stefan Hengelein , linux-kernel@vger.kernel.org Date: Thu, 23 Apr 2015 21:28:03 +0200 In-Reply-To: <5537E665.3010800@redhat.com> References: <5537E665.3010800@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-04-22 at 20:20 +0200, Denys Vlasenko wrote: > 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: > > config X86 > def_bool y > select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI > select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS > select ARCH_HAS_FAST_MULTIPLIER > select ARCH_HAS_GCOV_PROFILE_ALL > select ARCH_MIGHT_HAVE_PC_PARPORT > select ARCH_MIGHT_HAVE_PC_SERIO > select HAVE_AOUT if X86_32 > select HAVE_UNSTABLE_SCHED_CLOCK > select ARCH_SUPPORTS_NUMA_BALANCING if X86_64 > select ARCH_SUPPORTS_INT128 if X86_64 > select HAVE_IDE > select HAVE_OPROFILE > ... > > 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. No, those selects fill the .config with values as a direct consequence of the choices made by the person doing the configuration. You might just as well consider those values things that the user wanted to have too. > 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. So what? > 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? And lose the sanity checks that the kconfig tools provide? And the benefit of a having a single .config file showing the configuration the build will (or did) use? Anyhow, -ENOPATCH. Because I actually suspect that this scheme will complicate the tree quite a bit. Do send in patches showing how this scheme allows to drop a few Kconfig symbols. That makes it much easier to evaluate the pros and cons of your idea. Thanks, Paul Bolle