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

From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <julien@xen.org>
Subject: Ping: [PATCH v4 3/3] unzstd: make helper symbols static
Date: Wed, 30 Jun 2021 09:43:49 +0200	[thread overview]
Message-ID: <4a083cb0-9131-adbe-9be6-bc1ee3028eb0@suse.com> (raw)
In-Reply-To: <f6e00fd9-a207-858e-37e8-fb25427cf8de@xen.org>

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.

Thanks, Jan