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