Re: Ping: [PATCH v4 3/3] unzstd: make helper symbols static

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.06.2021 09:43, Jan Beulich wrote:
> On 05.05.2021 19:35, Julien Grall wrote:
>>
>>
>> On 29/04/2021 14:26, Jan Beulich wrote:
>>> On 29.04.2021 13:27, Julien Grall wrote:
>>>> On 21/04/2021 11:22, Jan Beulich wrote:
>>>>> While for the original library's purposes these functions of course want
>>>>> to be externally exposed, we don't need this, and we also don't want
>>>>> this both to prevent unintended use and to keep the name space tidy.
>>>>> (When functions have no callers at all, wrap them with a suitable
>>>>> #ifdef.) This has the added benefit of reducing the resulting binary
>>>>> size - while this is all .init code, it's still desirable to not carry
>>>>> dead code.
>>>>
>>>> So I understand the desire to keep the code close to Linux and removing
>>>> the dead code. However I am still not convinced that the approach taken
>>>> is actually worth the amount of memory saved.
>>>>
>>>> How much memory are we talking about here?
>>>
>>> There are no (runtime) memory savings, as is being said by the
>>> description. There are savings on the image and symbol table sizes
>>> (see below - .*.0/ holding files as produced without the patch
>>> applied, while .*.1/ holding output with it in place), the image
>>> size reduction part of which is - as also expressed by the
>>> description - a nice side effect, but not the main motivation for
>>> the change.
>>
>> Thanks for the providing the information. I have misunderstood your 
>> original intention.
>>
>> Reading them again, I have to admit this doesn't really change my view 
>> here. You are trading a smaller name space or prevent unintended use 
>> (not clear what would be wrong to call them) to code 
>> maintenability/readability.
>>
>> At the same time, this is not a code I usually work on (even if I am 
>> meant to maintain it). I will leave another maintainer to make the 
>> decision here.
> 
> May I ask for another REST maintainer's view here? If there's support
> for Julien's position, then I'll at least know to drop the patch. Of
> course I'd prefer it, or a stripped down version of it, to go in.

FTR - a response to this was iirc supplied on a community call (by
Andrew), requesting to actually delete the sections of code enclosed
in BUILD_DEAD_CODE conditionals. I've been pondering the request for
quite some time, and I've now come to the conclusion that I do not
want to do so. Hence, while I'm not happy about this, I'll treat this
patch as rejected.

Jan