Re: [PATCH for-4.18 v5] xen/pdx: Make CONFIG_PDX_COMPRESSION a common Kconfig option

[Jan Beulich <jbeulich@suse.com>]

On 06.10.2023 18:01, Andrew Cooper wrote:
> On 06/10/2023 4:09 pm, Julien Grall wrote:
>>
>>
>> On 06/10/2023 15:44, Andrew Cooper wrote:
>>> From: Alejandro Vallejo <alejandro.vallejo@cloud.com>
>>>
>>> Adds a new compile-time flag to allow disabling PDX compression and
>>> compiles out compression-related code/data. It also shorts the pdx<->pfn
>>> conversion macros and creates stubs for masking functions.
>>>
>>> While at it, removes the old arch-defined CONFIG_HAS_PDX flag. 
>>> Despite the
>>> illusion of choice, it was not optional.
>>>
>>> There are ARM and PPC platforms with sparse RAM banks - leave compression
>>> active by default there.  OTOH, there are no known production x86
>>> systems with
>>> sparse RAM banks, so disable compression.  This decision can be
>>> revisited if
>>> such a platform comes along.
>>
>> (Process remarks rather than the code itself)
>>
>> Jan is away this week so I want to make sure this doesn't go in without
>> him having a say.
>>
>> While I don't particularly care about the approach taken for x86, Jan
>> voiced concerned with this approach and so far I didn't see any
>> conclusion. If there is any, then please point me to them.
>>
>> For the record, the objections from Jan are in [1]. If we want to ignore
>> them, then I think we need a vote. Possibly only from the x86 folks (?).
> 
> What do you think the 2 x86 maintainer tags on this patch in this exact
> form, following far too much wasted time already, represents.  The vote
> has already concluded.

In a reply separate from his R-b he also said "I would be fine in leaving
the option to be selected if ...", so I don't think you can count tags as
votes. As much as you apparently have a hard time seeing why I want the
option to remain available (despite knowing why I introduced PDX back at
the time), I'm having a hard time seeing why you want it unilaterally off
(and I'm afraid I haven't seen any reasoning beyond you simply not liking
that code, and you also not having liked my earlier attempts to overcome
the undue overhead).

Jan