On 30.10.2023 16:14, Roger Pau Monné wrote: > On Mon, Oct 30, 2023 at 01:24:52PM +0100, Jan Beulich wrote: >> On 26.10.2023 17:19, Roger Pau Monné wrote: >>> Maybe the issue is that PV_SHIM_EXCLUSIVE shouldn't have been a >>> Kconfig option in the first place, and instead a specific Kconfig >>> config file? >>> >>> Maybe it's not possible to achieve the same using just a Kconfig >>> config file. >> >> I'm afraid I don't understand what you mean by "Kconfig config file". It >> can't really be just another .../Kconfig file somewhere in the tree, as >> it doesn't really matter where an option like this would be defined. > > No, I was thinking of splitting what PV_SHIM_EXCLUSIVE actually > implies, for example by adding CONFIG_DOMCTL_HYPERCALLL or > CONFIG_PLATFORM_HYPERCALL and re-work the pvshim_defconfig config file > based on those, so that we don't end up with negative relations. > > Note sure all usages of PV_SHIM_EXCLUSIVE can be split in such a way, > maybe we would need some compromise.
Wouldn't such a CONFIG_DOMCTL_HYPERCALL then still want to depend on !PV_SHIM_EXCLUSIVE, which is the kind of dependency we want to avoid? Aiui the two (splitting and inverting) are largely orthogonal aspects. Jan
