Re: [Xen-devel] [PATCH v2 21/23] x86: expose CONFIG_HVM

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 30/08/18 07:21, Jan Beulich wrote:
>>>>>> +
>>>>>> +          If unsure, say Y.
>>>>>> +
>>>>>>  
>>>>>>  config SHADOW_PAGING
>>>>> No double blank lines please.
>>>>>
>>>>> My previously voiced reservations wrt the shim remain. I continue
>>>>> to disagree with Andrew that the symbol needs to be visible in a
>>>>> shim-only config, and I continue to demand as a minimum that the
>>>>> default here be N in that case if the symbol really is to remain visible.
>>>> Conditionally influencing the default is fine.  Hiding the symbol is not.
>>>>
>>>> To be very very clear, I will nack/revert any patch which tries to
>>>> insert a dependency here.  I find your reasoning to be wrong, and
>>>> sufficiently short sighted and detrimental to users, that I'm not going
>>>> to let the patch in.
>>> Since iirc you didn't respond to my most recent comment on v1 here,
>>> I would have very much hoped you'd explain your position a little
>>> better than just claiming that the symbol becoming invisible with a
>>> dependency added is a bad thing. I'm certainly open to (good)
>>> arguments, but I'm not accepting a plain statement without proper
>>> explanation.
>> I'm not sure how to put this any more clearly.
>>
>> Our users cannot read *your* mind when they are trying to use `make
>> menuconfig`.
>>
>> Since our users are not experts in Xen, the lack of an HVM option is
>> going to cause confusion and questions to mailing lists/IRC, rather than
>> the realisation that (obviously?) they needed to disable
>> PV_SHIM_EXCLUSIVE first.
> But that's an argument to remove support for "depends on" altogether
> from the kconfig sources.

Nonsense.  That is not a remotely plausible interpretation of what I said.

Dependences are normal and expected for functionality built on top of
each other.  What makes this easy and logical for people to navigate is
that dependencies are normally a self-contained directed acyclic tree.

In this case, you're adding a link between a leaf at the bottom of the
PV tree which chops off the entire HVM tree, and it is dependences like
this which are confusing for users (who are not experts) to navigate.

If something is going to malfunction (fail to compile/crash on boot/etc)
then a dependency is the correct tool to use.  Having a slightly fat
binary with some unused code is not the same class of problem, and
should not be treated as if they are the same.

>  I'm not buying this as an argument. Option
> combinations that make no sense should not be permitted, _in the very
> interest of users who are no experts in Xen_.

I'll address "makes no sense" below, but as to permitted...

It is impossible to offer people flexibility, and prevent them from
getting into every conceivable problematic scenario.  At some point you
have to trust that they have accepted some responsibility for the
outcome by modifying .config, and they are capable of the elementary
reasoning such as "oh. that didn't work.  perhaps I should undo it".

>
> Furthermore I can only express my personal feelings for "make
> menuconfig" and alike - just don't use it.

You might enjoy/prefer manually editing .config.  You are free and
welcome to do so.

It is naive to presume that everyone else will agree with your choices
and opinions, and especially in this case as menuconfig is by far the
most common way users edit their configuration.  (So much so that I
can't find a tutorial online which uses anything other than menuconfig,
whether for linux or for other projects which have borrowed Kconfig like
we have.)

>
>> Finally (and minor in comparison), from the point of view of keeping our
>> interfaces clean, we'll want Randconfig to occasionally test with both
>> of them enabled.
> Why, when the combination doesn't make sense?

Case in point, "x86: use VMLOAD for PV context switch".

A user wanting to run PVShim most efficiently on an AMD Fam17h (which
has virtual vmload/save support) would enable nested virt and want to
use vmload support.  Such a user would want both
CONFIG_PV_SHIM_EXCLUSIVE and CONFIG_HVM enabled.

> Anyway - I'm extending the Cc list to get the more general underlying
> question resolved. To those who haven't followed the discussion from
> the beginning: The question is whether senseless combinations of
> Kconfig options should be permitted, or whether instead "depends on"
> is a reasonable thing to use in such cases to prevent their (combined)
> selection.

The people whose opinions matter most here are those who build/package
Xen, who are not developers and therefore not experts in how the
hypervisor fits together.

If it turns out that the majority of users disagree with me, then I'll
withdraw my nack, but the reason I'm being such a pain in this regard is
that this thread re-enforces my opinion that your judgement here is
wrong, is actively detrimental to usability (which is far wider than
just developer usability), and that the users will agree with me in this
matter.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel