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@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
