On 28/08/18 14:33, Jan Beulich wrote: >>>> On 28.08.18 at 14:14, <andrew.coop...@citrix.com> wrote: >> On 28/08/18 12:50, Jan Beulich wrote: >>>>>> On 26.08.18 at 14:19, <wei.l...@citrix.com> 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. It does not matter if people accidentally select both options, because they'll end up with the same build as exists today, and a fractionally larger than necessary hypervisor. It does matter that people can sensibly navigate the menu without unnecessary confusion. 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
