On 22.01.2025 10:49, Roger Pau Monné wrote: > On Wed, Jan 22, 2025 at 09:43:53AM +0100, Jan Beulich wrote: >> On 21.01.2025 19:02, Roger Pau Monné wrote: >>> On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote: >>>> On 21.01.2025 09:52, Roger Pau Monné wrote: >>>>> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote: >>>>>> On 21.01.2025 00:27, Stefano Stabellini wrote: >>>>>>> If I understood it right, I like Andrew's suggestion. He is suggesting >>>>>>> to do the following: >>>>>>> >>>>>>> - turning PV_SHIM_EXCLUSIVE into something that does nothing >>>>>> >>>>>> FTAOD - you mean Kconfig-wise? Andrew clearly didn't say "nothing", but >>>>>> "nothing other than making the boolean be a compile time constant". >>>>> >>>>> Won't making the boolean a compile time constant would also result in >>>>> DCO kicking in and removing a fair amount of code? So even if you >>>>> have enabled everything in Kconfig, the resulting hypervisor would >>>>> only be suitable to be used as a shim? >>>> >>>> Of course. >>> >>> Then what's the point of this approach? Options will be enabled in >>> Kconfig, but the resulting hypervisor build when using allyesconfig >>> would have a lot of them short-circuited, making it even worse than >>> currently? As options will get effectively build-time disabled due >>> to DCO while enabled in Kconfig. >> >> Well, I have to direct this question to Andrew. It is specifically >> what I'm trying to address with UNCONSTRAINED. >> >>> Overall I think PV_SHIM_EXCLUSIVE should be excluded from >>> allyesconfig, even with Andrew's proposed change. Otherwise the >>> purpose of allyesconfig is defeated if enabling PV_SHIM_EXCLUSIVE >>> makes the resulting hypervisor build PV shim only. IIRC we can >>> provide a default alllyes.config with CONFIG_PV_SHIM_EXCLUSIVE=n. >> >> Hmm, I wasn't aware of the option of using allyes.config. That might be >> the route to go, albeit it looks like people using the allyesconfig >> target then need to remember to set KCONFIG_ALLCONFIG in the environment >> (to <empty> or 1), or to explicitly specify a file name that way. (This >> of course ought to be easy enough to arrange for in our automation.) > > My knowledge of Kconfig is very limited, but isn't there a default > path for such file to be picked up by Kconfig? I see we already have > a xen/tools/kconfig/allrandom.config, I was expecting it would be a > matter of dropping an allyes.config in that directory, but I haven't > tried.
Well, I simply looked at the kconfig sources, and my reading of it is that it won't even try to open allyes.config when the envvar is absent. Jan
