[PATCH 4/5] log: convert pr_*() to logging

[Tom Rini]

On Mon, Jan 18, 2021 at 08:02:41AM -0500, Tom Rini wrote:
> On Sun, Jan 17, 2021 at 08:37:15AM +0100, Heinrich Schuchardt wrote:
> > On 1/17/21 1:16 AM, Tom Rini wrote:
> > > On Mon, Jan 04, 2021 at 08:02:55AM +0100, Heinrich Schuchardt wrote:
> > > 
> > > > In drivers we use a family of printing functions including pr_err() and
> > > > pr_cont(). CONFIG_LOGLEVEL is used to control which of these lead to output
> > > > via printf().
> > > > 
> > > > Our logging functions allow finer grained control of output. So replace
> > > > printf() by the matching logging functions. The usage of CONFIG_LOGLEVEL
> > > > remains unchanged.
> > > > 
> > > > Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > > > ---
> > > >   include/linux/bitops.h |  4 ++-
> > > >   include/linux/printk.h | 82 +++++++++++++++++++++++-------------------
> > > >   2 files changed, 48 insertions(+), 38 deletions(-)
> > > 
> > > This causes some fairly massive growth in various subsystems such as ubi
> > > and we might want to look at what, if anything, we can do, before
> > > growing some platforms by 15KiB (xilinx_zynqmp_virt) due to strings.
> > 
> > xilinx_zynqmp_virt has CONFIG_LOG enabled. Switching from printf() to
> > log() incurs size growth. Did you observe a size grows on platforms with
> > CONFIG_LOG=n?
> 
> Yes, it has logging enabled, and we're converting a large number of
> things that were before compile-time discarded to no longer be so.  This
> is, in general, good and what I've asked for.  But when seeing very
> large growth in doing so, I think we need to maybe take a step back and
> look at the UBI subsystem for example and see if we can't/shouldn't
> tweak things more.
> 
> So, I'm going to run a size test with just this patch as the change, so
> we can have more concrete numbers to look at.

OK, so the build is done and interesting output starts at:
https://gist.github.com/trini/53e7da62c6c9d18c189e6baffd01ff00#file-2021-01-18-0800-txt-L239

Most of the time we're well under 1KiB, which is great.  UBI has some
huge growth, but it's a very few platforms, and I've added the
custodians here so they can object, or not, to such size growth.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210118/c35d6714/attachment.sig>