Re: [PATCH v2] xen: EXPERT clean-up and introduce UNSUPPORTED

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.11.2020 22:40, Stefano Stabellini wrote:
> On Thu, 19 Nov 2020, Jan Beulich wrote:
>> On 18.11.2020 22:00, Stefano Stabellini wrote:
>>> On Wed, 18 Nov 2020, Jan Beulich wrote:
>>>> On 18.11.2020 01:50, Stefano Stabellini wrote:
>>>>> 1) It is not obvious that "Configure standard Xen features (expert
>>>>> users)" is actually the famous EXPERT we keep talking about on xen-devel
>>>>
>>>> Which can be addressed by simply changing the one prompt line.
>>>>
>>>>> 2) It is not obvious when we need to enable EXPERT to get a specific
>>>>> feature
>>>>>
>>>>> In particular if you want to enable ACPI support so that you can boot
>>>>> Xen on an ACPI platform, you have to enable EXPERT first. But searching
>>>>> through the kconfig menu it is really not clear (type '/' and "ACPI"):
>>>>> nothing in the description tells you that you need to enable EXPERT to
>>>>> get the option.
>>>>
>>>> And what causes this to be different once you switch to UNSUPPORTED?
>>>
>>> Two things: firstly, it doesn't and shouldn't take an expert to enable
>>> ACPI support, even if ACPI support is experimental. So calling it
>>> UNSUPPORTED helps a lot. This is particularly relevant to the ARM Kconfig
>>> options changed by this patch. Secondly, this patch is adding
>>> "(UNSUPPORTED)" in the oneline prompt so that it becomes easy to match
>>> it with the option you need to enable.
>>
>> There's redundancy here then, which I think is in almost all cases
>> better to avoid. That's first and foremost because the two places
>> can go out of sync. Therefore, if the primary thing is to help
>> "make menuconfig" (which I admit I don't normally use, as it's
>> nothing that gets invoked implicitly by the build process afaict,
>> i.e. one has to actively invoke it), perhaps we should enhance
>> kconfig to attach at least a pre-determined subset of labels to
>> the prompts automatically?
>>
>> And second, also in reply to what you've been saying further down,
>> perhaps we would better go with a hierarchy of controls here, e.g.
>> EXPERT -> EXPERIMENTAL -> UNSUPPORTED?
> 
> Both these are good ideas worth discussing; somebody else made a similar
> suggestion some time back. I was already thinking this could be a great
> candidate for one of the first "working groups" as defined by George
> during the last community call because the topic is not purely
> technical: a working group could help getting alignment and make
> progress faster. We can propose it to George when he is back.
> 
> However, I don't think we need the working group to make progress on
> this limited patch that only addresses the lowest hanging fruit.
> 
> I'd like to suggest to make progress on this patch in its current form,
> and in parallel start a longer term discussion on how to do something
> like you suggested above.

Okay, I guess I can accept this. So FAOD I'm not objecting to the
change (with some suitable adjustments, as discussed), but I'm
then also not going to be the one to ack it. Nevertheless I'd like
to point out that doing such a partial solution may end up adding
confusion rather than reducing it. Much depends on how exactly
consumers interpret what we hand to them.

Jan