[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 6 May 2021 08:21:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o2u+aTEFkhpm5mkgF4eOF0+Eb37M6Aq5WLNTwUg+GkY=; b=Ib1I6boMGKBMUHulCP1q5HQIOib8fP/VBwurbCj9fzJ2M4A2uCykJoJ2w1Z2F6sNJyskT+3KxNi44UESX2B5rp21XIYVQGxvBOBkrCtB+oHK8K2fkhJaLl/zHoNoM4CiyiMG/LxzVWYT1rslANE8saFtaQS1PS+VavxY4ur83WzjiRMd78fsW94x9vKlB1HfYVv0AuPKqeofPEnzupiOMzIu5nG5jE/QblBYHdqndi4c93XNVT+Ek7uyjoyO4OV5TVkOJbQTJVPItSv79eQ/oC+WSvLIkOXBCnncpuBi9VwkQY8IWGJ/JrYR8bVAuN7GeG0tEGxAlp5MjlcQxuNEfA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m0OUI6siT1KJFpxRQ/meKFsFJWIyR01CyLOvq4RCsPH3aCyXeCrhjDMtiGrGeXlVj0+S6JOdyaAkHFOzaLSkpNMnk+gUzwx1QUaGRiz2QvfvhFwWH2Kuw9nkzziaGMiBUuRkH5HIJvgYvu7+I4VOGNkpkL/ht7dyw/lipoV8/MeCy1eqCB7/KlmeUD7sVjvKaFrijvDLaBMNDg7LpPhVRb43ag0mnhg88aI4AKeOqRbfVZttxkV4FpoV8JasApkIFGWBeqvBOg8aGqKOdqC8oSslnbdPdU/qugIlPhxP/23rIGthpozVws4cQE+XR+qd/r3iGccvHCxxhCMsZZFzTg==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 06 May 2021 06:21:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.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.

Well, I mean mainly the usual issue of us, short of having Linux-like
section reference checking, being at risk of calling __init functions
from non-__init code. This risk exists with every single such symbol,
and hence I view it as helpful to reduce overall risk by limiting the
number of such symbols to the actually useful ones.

> 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.

Fair enough. Thanks anyway for looking here, and for all the other
acks on this (originally larger) series.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.