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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.08.18 at 18:56, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/08/18 14:33, Jan Beulich wrote:
>>>>> On 28.08.18 at 14:14, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 28/08/18 12:50, Jan Beulich wrote:
>>>>>>> On 26.08.18 at 14:19, <wei.liu2@xxxxxxxxxx> wrote:
>>>>> --- a/xen/arch/x86/Kconfig
>>>>> +++ b/xen/arch/x86/Kconfig
>>>>> @@ -60,6 +60,12 @@ config PV_LINEAR_PT
>>>>>  
>>>>>  config HVM
>>>>>   def_bool y
>>>>> + prompt "HVM / PVH support"
>>>>> + ---help---
>>>>> +   Interfaces to support HVM and PVH guests.
>>> This definitely needs more than a single line...
>>>
>>>>> +
>>>>> +   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. 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_.

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

> 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?

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.

Jan



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