On Thu, Sep 8, 2022 at 8:24 PM Mike Rapoport <rppt@xxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 08, 2022 at 12:43:36PM +0200, Lukas Bulwahn wrote:
> > 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 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.
> >
> > Currently, in v6.0-rc4, SECRETMEM is the only config switched off if
> > CONFIG_EMBEDDED=y.
> >
> > As long as that is actually the only option that currently is selected or
> > deselected, it is better to just make SECRETMEM configurable at build time
> > by experts using menuconfig instead.
> >
> > Make SECRETMEM configurable when EXPERT is set and otherwise default to
> > yes. Further, SECRETMEM needs ARCH_HAS_SET_DIRECT_MAP.
> >
> > This allows us to remove CONFIG_EMBEDDED in the close future.
> >
> > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx>
>
> Acked-by: Mike Rapoport <rppt@xxxxxxxxxxxxx>
>
> > ---
> > mm/Kconfig | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index ceec438c0741..aa154c20b129 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -1068,7 +1068,13 @@ config IO_MAPPING
> > bool
> >
> > config SECRETMEM
> > - def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
> > + default y
> > + bool "Enable memfd_secret() system call" if EXPERT
> > + depends on ARCH_HAS_SET_DIRECT_MAP
> > + help
> > + Enable the memfd_secret() system call with the ability to create
> > + memory areas visible only in the context of the owning process and
> > + not mapped to other processes and other kernel page tables.
> >
> > config ANON_VMA_NAME
> > bool "Anonymous VMA name support"
> > --
> > 2.17.1
> >
>
> --
> Sincerely yours,
> Mike.
Reviewed-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
--
Best Regards
Masahiro Yamada
