linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	Peter Chen <peter.chen@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	"linux-kbuild@vger.kernel.org" <linux-kbuild@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: "kernel-janitors@vger.kernel.org"
	<kernel-janitors@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 6/6] init/Kconfig: remove confusing config EMBEDDED
Date: Fri, 9 Sep 2022 09:23:48 +0000	[thread overview]
Message-ID: <ca25a32d-aadb-f0d0-9e24-70fbabc4d377@csgroup.eu> (raw)
In-Reply-To: <20220908104337.11940-7-lukas.bulwahn@gmail.com>

+ linuxppc-dev

Le 08/09/2022 à 12:43, Lukas Bulwahn a écrit :
> Commit 6a108a14fa35 ("kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT")
> introduces CONFIG_EXPERT to carry the previous intent of CONFIG_EMBEDDED
> and just gives that intent a much better name. That has been clearly a good
> and long overdue renaming, and it is clearly an improvement to the kernel
> build configuration that has shown to help managing the kernel build
> configuration in the last decade.
> 
> However, rather than bravely and radically just deleting CONFIG_EMBEDDED,
> this commit gives CONFIG_EMBEDDED a new intended semantics, but keeps it
> open for future contributors to implement that intended semantics:
> 
>      A new CONFIG_EMBEDDED option is added that automatically selects
>      CONFIG_EXPERT when enabled and can be used in the future to isolate
>      options that should only be considered for embedded systems (RISC
>      architectures, SLOB, etc).
> 
> Since then, this CONFIG_EMBEDDED implicitly had two purposes:
> 
>    - It can make even more options visible beyond what CONFIG_EXPERT makes
>      visible. In other words, it may introduce another level of enabling the
>      visibility of configuration options: always visible, visible with
>      CONFIG_EXPERT and visible with CONFIG_EMBEDDED.
> 
>    - Set certain default values of some configurations differently,
>      following the assumption that configuring a kernel build for an
>      embedded system generally starts with a different set of default values
>      compared to kernel builds for all other kind of systems.
> 
> Considering the first purpose, at the point in time where CONFIG_EMBEDDED
> was renamed to CONFIG_EXPERT, CONFIG_EXPERT already made 130 more options
> become visible throughout all different menus for the kernel configuration.
> Over the last decade, this has gradually increased, so that currently, with
> CONFIG_EXPERT, roughly 170 more options become visible throughout all
> different menus for the kernel configuration. In comparison, currently with
> CONFIG_EMBEDDED enabled, just seven more options are visible, one in x86,
> one in arm, and five for the ChipIdea Highspeed Dual Role Controller.
> 
> As the numbers suggest, these two levels of enabling the visibility of even
> more configuration options---beyond what CONFIG_EXPERT enables---never
> evolved to a good solution in the last decade. In other words, this
> additional level of visibility of configuration option with CONFIG_EMBEDDED
> compared to CONFIG_EXPERT has since its introduction never become really
> valuable. It requires quite some investigation to actually understand what
> is additionally visible and it does not differ significantly in complexity
> compared to just enabling CONFIG_EXPERT. This CONFIG_EMBEDDED---or any
> other config to show more detailed options beyond CONFIG_EXPERT---is
> unlikely to be valuable unless somebody puts significant effort in
> identifying how such visibility options can be properly split and creating
> clear criteria, when some config option is visible with CONFIG_EXPERT and
> when some config option is visible only with some further option enabled
> beyond CONFIG_EXPERT, such as CONFIG_EMBEDDED attempted to do. For now, it
> is much more reasonable to simply make those additional seven options that
> visible with CONFIG_EMBEDDED, visible with CONFIG_EXPERT, and then remove
> CONFIG_EMBEDDED. If anyone spends significant effort in structuring the
> visibility of config options, they may re-introduce suitable new config
> options simply as they see fit.
> 
> Hence, all uses of CONFIG_EMBEDDED have been replaced with CONFIG_EXPERT.
> 
> Considering the second purpose, note that already probably arguing that a
> kernel build for an embedded system would choose some values differently is
> already tricky: the set of embedded systems with Linux kernels is already
> quite diverse. Many embedded system have powerful CPUs and it would not be
> clear that all embedded systems just optimize towards one specific aspect,
> e.g., a smaller kernel image size. So, it is unclear if starting with "one
> set of default configuration" that is induced by CONFIG_EMBEDDED is a good
> offer for developers configuring their kernels.
> 
> Also, the differences of needed user-space features in an embedded system
> compared to a non-embedded system are probably difficult or even impossible
> to name in some generic way.
> 
> So it is not surprising that in the last decade hardly anyone has
> contributed changes to make something default differently in case of
> CONFIG_EMBEDDED=y.
> 
> In v6.0-rc4, SECRETMEM is the only config switched off if
> CONFIG_EMBEDDED=y. That one use was removed as well, SECRETMEM was made
> configurable at build time by experts using menuconfig instead.
> 
> As there are no further uses of CONFIG_EMBEDDED and CONFIG_EMBEDDED never
> lived up to its intended purpose defined above, simply delete this
> confusing CONFIG_EMBEDDED.
> 
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
>   init/Kconfig | 8 --------
>   1 file changed, 8 deletions(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 9e3fd79b089c..d7429e0b8cae 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1818,14 +1818,6 @@ config DEBUG_RSEQ
>   
>   	  If unsure, say N.
>   
> -config EMBEDDED
> -	bool "Embedded system"
> -	select EXPERT
> -	help
> -	  This option should be enabled if compiling the kernel for
> -	  an embedded system so certain expert options are available
> -	  for configuration.
> -
>   config HAVE_PERF_EVENTS
>   	bool
>   	help

That's fine, but what happens to existing defconfigs then ?

$ git grep -w CONFIG_EMBEDDED arch/powerpc/
arch/powerpc/configs/40x/klondike_defconfig:CONFIG_EMBEDDED=y
arch/powerpc/configs/44x/fsp2_defconfig:CONFIG_EMBEDDED=y
arch/powerpc/configs/52xx/tqm5200_defconfig:CONFIG_EMBEDDED=y
arch/powerpc/configs/mgcoge_defconfig:CONFIG_EMBEDDED=y
arch/powerpc/configs/microwatt_defconfig:CONFIG_EMBEDDED=y
arch/powerpc/configs/ps3_defconfig:CONFIG_EMBEDDED=y

They need to get converted to selecting CONFIG_EXPERT instead.

And that needs to be done before you remove CONFIG_EMBEDDED.

Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2022-09-09  9:25 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-08 10:43 [PATCH 0/6] Remove CONFIG_EMBEDDED Lukas Bulwahn
2022-09-08 10:43 ` [PATCH 1/6] arm: make config ARM_PATCH_PHYS_VIRT visible with EXPERT Lukas Bulwahn
2022-09-09  6:21   ` Masahiro Yamada
2022-09-08 10:43 ` [PATCH 2/6] x86: make config X86_FEATURE_NAMES " Lukas Bulwahn
2022-09-09  6:22   ` Masahiro Yamada
2022-09-08 10:43 ` [PATCH 3/6] media: remove reference to CONFIG_EMBEDDED in MEDIA_SUPPORT_FILTER Lukas Bulwahn
2022-09-08 11:13   ` Mauro Carvalho Chehab
2022-09-08 16:20     ` Mauro Carvalho Chehab
2022-09-09  6:22       ` Masahiro Yamada
2022-09-08 10:43 ` [PATCH 4/6] usb: chipidea: make configs for glue drivers visible with EXPERT Lukas Bulwahn
2022-09-08 11:33   ` Greg Kroah-Hartman
2022-09-09  6:22     ` Masahiro Yamada
2022-09-08 10:43 ` [PATCH 5/6] mm: Kconfig: make config SECRETMEM " Lukas Bulwahn
2022-09-08 11:24   ` Mike Rapoport
2022-09-09  6:22     ` Masahiro Yamada
2022-09-08 10:43 ` [PATCH 6/6] init/Kconfig: remove confusing config EMBEDDED Lukas Bulwahn
2022-09-09  6:24   ` Masahiro Yamada
2022-09-09  9:23   ` Christophe Leroy [this message]
2022-09-09  9:47     ` Lukas Bulwahn
2022-09-08 15:21 ` [PATCH 0/6] Remove CONFIG_EMBEDDED Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca25a32d-aadb-f0d0-9e24-70fbabc4d377@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=masahiroy@kernel.org \
    --cc=mchehab@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peter.chen@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).