[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] xen: EXPERT clean-up and introduce UNSUPPORTED
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Rich Persaud <persaur@xxxxxxxxx>
- Date: Sat, 21 Nov 2020 05:53:50 -0500
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, andrew.cooper3@xxxxxxxxxx, Bertrand.Marquis@xxxxxxx, Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>, george.dunlap@xxxxxxxxxx, iwj@xxxxxxxxxxxxxx, julien@xxxxxxx, wl@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, Christopher Clark <christopher.w.clark@xxxxxxxxx>, Roman Shaposhnik <roman@xxxxxxxxxx>, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Sat, 21 Nov 2020 10:54:14 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Nov 20, 2020, at 05:09, Jan Beulich <jbeulich@xxxxxxxx> wrote: 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 thechange (with some suitable adjustments, as discussed), but I'mthen also not going to be the one to ack it. Nevertheless I'd liketo point out that doing such a partial solution may end up addingconfusion rather than reducing it.
Seconded. Much depends on how exactly consumers interpret what we hand to them.
How have Xen consumers changed during the last 15 years? The UX (user experience) community uses a technique called "user stories" [0][1][2]. It may be worth writing a few sentences about the users (distro packagers? Xen derivatives? hypervisor developers? hosting companies? malware developers?) whose needs are addressed by proposed changes. One could then reason about UX of Xen feature selection, before and after proposed changes.
Rich
|
|
