Re: [RFC PATCH] xen: EXPERT clean-up

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 2 Nov 2020, Jan Beulich wrote:
> On 31.10.2020 01:24, Stefano Stabellini wrote:
> > --- a/xen/Kconfig
> > +++ b/xen/Kconfig
> > @@ -35,14 +35,13 @@ config DEFCONFIG_LIST
> >     default ARCH_DEFCONFIG
> >  
> >  config EXPERT
> > -   bool "Configure standard Xen features (expert users)"
> > +   bool "Configure EXPERT features"
> >     help
> > -     This option allows certain base Xen options and settings
> > -     to be disabled or tweaked. This is for specialized environments
> > -     which can tolerate a "non-standard" Xen.
> > -     Only use this if you really know what you are doing.
> > -     Xen binaries built with this option enabled are not security
> > -     supported.
> > +     This option allows certain experimental (see SUPPORT.md) Xen
> > +     options and settings to be enabled/disabled. This is for
> > +     specialized environments which can tolerate a "non-standard" Xen.
> > +     Only use this if you really know what you are doing.  Xen binaries
> > +     built with this option enabled are not security supported.
> >     default n
> 
> I'm definitely in favor of this - it was more than once that I
> wondered about the prompt text.

Thanks, I agree!


> > @@ -79,8 +79,8 @@ config SBSA_VUART_CONSOLE
> >       SBSA Generic UART implements a subset of ARM PL011 UART.
> >  
> >  config ARM_SSBD
> > -   bool "Speculative Store Bypass Disable" if EXPERT
> > -   depends on HAS_ALTERNATIVE
> > +   bool "Speculative Store Bypass Disable"
> > +   depends on HAS_ALTERNATIVE && EXPERT
> >     default y
> 
> At the example of this, I'm afraid when the default isn't "n"
> (or there's no default directive at all, as ought to be
> equivalent to and preferred over "default n"), such a
> transformation is not functionally identical: Before your
> change, with !EXPERT this option defaults to y. After your
> change this option is unavailable (which resolves to it being
> off for all consuming purposes).
> 
> IOW there are reasons to have "if ..." attached to the prompts
> (for this construct indeed only making the prompt conditional,
> not the entire option), but there are also cases where the
> cleanup you do is indeed desirable / helpful.

Yeah, thanks for catching it, it is obviously a problem.

My intention was just to "tag" somehow the options to EXPERT so that it
would show on the menu. Maybe a better, simpler, way to do it is
to add the word "EXPERT" to the one line prompt:

 config ARM_SSBD
-       bool "Speculative Store Bypass Disable" if EXPERT
+       bool "Speculative Store Bypass Disable (EXPERT)" if EXPERT
        depends on HAS_ALTERNATIVE
        default y
        help


What do you think?