Re: [PATCH] xen/arm: Remove EXPERT dependancy

[Elliott Mitchell <ehem+xen@xxxxxxx>]

On Mon, Oct 26, 2020 at 09:19:49AM +0000, Julien Grall wrote:
> On 23/10/2020 17:57, Stefano Stabellini wrote:
> > On Fri, 23 Oct 2020, Julien Grall wrote:

> >> I am sort of okay to remove EXPERT.
> > 
> > OK. This would help (even without building it by default) because as you
> > go and look at the menu the first time, you'll find ACPI among the
> > options right away.
> 
> To be honest, this step is probably the easiest in the full process to 
> get Xen build and booted on Arm.
> 
> I briefly looked at Elliot's v2, and I can't keep thinking that we are 
> trying to re-invent EXPERT for ACPI because we think the feature is 
> *more* important than any other feature gated by EXPERT.

Yet might that statement in fact be true?

Most of the features currently controlled by CONFIG_EXPERT are relatively
small tweaks which enable less often used features.  Some of those are
very high value in certain environments, but they're unimportant in
common environments.  Changing the scheduler might get you an extra
10-50% performance improvement in a special environment.

ACPI support isn't like this.  I'm unaware what Masami Hiramatsu's system
does if a CONFIG_ACPI=n Xen build is tried.  I haven't actually tried
such a build on mine, but from the code it looks like Xen would panic if
built that way.  No output of any sort.  Simply panic with the device
appearing to go inert.

> In fact, all the features behind EXPERT are important. But they have 
> been gated by EXPERT because they are not mature enough.

> But I don't think ACPI is mature enough to deserve a different 
> treatment. It would be more useful to get to the stage where ACPI can 
> work without any crash/issue first.

The difference is the severity of failure if the option is off, but needs
to be on.  Most CONFIG_EXPERT options will merely be performance
reductions or security situations unacceptable to some users.
CONFIG_ACPI=n on the wrong system could be a panic with *no* output.


Tainting sounds reasonable.  Messages in `dmesg` make sense.  A message
plus 10 second pause on boot seems reasonable.  I think if CONFIG_ACPI is
off, there should be code to try to detect ACPI and emit a warning if
anything is detected.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@xxxxxxx  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445