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 <[email protected]> > 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 also don't see why this patch needs to come here in the series. The main refactoring in the following two patches looks to be independent. ~Andrew
