On 18.07.2023 11:35, Andrew Cooper wrote: > On 18/07/2023 10:19 am, Jan Beulich wrote: >> On 17.07.2023 18:03, Alejandro Vallejo wrote: >>> It's set everywhere and can't be turned off because it's presence is >>> assumed in several parts of the codebase. This is an initial patch towards >>> adding a more fine-grained CONFIG_HAS_PDX_COMPRESSION that can actually be >>> disabled on systems that don't typically benefit from it. >>> >>> No functional change. >>> >>> Signed-off-by: Alejandro Vallejo <alejandro.vall...@cloud.com> >> On its own I don't think this is okay, as it's unclear whether it would >> affect RISC-V or PPC in a negative way. > > Neither could compile without layering violations of PDX logic in common > code, and neither have got that far yet. > > Now is an excellent time to be doing this, because it removes work for > RISC-V/PPC... > >> If at all, it should only go in >> together with the later re-introduction of a CONFIG_*. Still I question >> whether that new CONFIG_HAS_PDX_COMPRESSION (which imo ought to be >> CONFIG_PDX_COMPRESSION) then wouldn't better depend on the arch-selected >> HAS_PDX, such that it wouldn't wrongly be offered to choose a value when >> compression isn't supported in the first place. > > ... although I do agree that the resulting option shouldn't be user > selectable. It's a property of the architecture, not something a user > should be worrying about.
I disagree. Exotic x86 hardware may or may not want supporting, which can only be determined by the build meister, as long as this is indeed meant to become a build-time decision (rather than a runtime one; see my response to the cover letter of this series). Jan
