U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Patrice CHOTARD <patrice.chotard@foss.st.com>
To: u-boot@lists.denx.de
Subject: [PATCH 4/5] log: convert pr_*() to logging
Date: Thu, 18 Feb 2021 16:04:56 +0100	[thread overview]
Message-ID: <e5fdcee2-c112-197c-48ef-b74eb7132553@foss.st.com> (raw)
In-Reply-To: <20210218130557.GE10169@bill-the-cat>

Hi Tom

On 2/18/21 2:05 PM, Tom Rini wrote:
> On Thu, Feb 18, 2021 at 10:16:58AM +0100, Heinrich Schuchardt wrote:
>> On 18.01.21 16:30, Tom Rini wrote:
>>> 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@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.
>>>
>>
>> Hello Tom,
>>
>> How shall we proceed?
> 
> Michal? Patrice or Patrick?  Since this patch causes noticeable growth
> on your platforms I'm waiting for your input here, to be clear.  Thanks!
> 

No objection for stm32 platforms, ok for us ;-)

Patrice

  reply	other threads:[~2021-02-18 15:04 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-04  7:02 [PATCH 0/5] log: convert pr_*() to logging Heinrich Schuchardt
2021-01-04  7:02 ` [PATCH 1/5] ram: k3-j721e: rename BIT_MASK() Heinrich Schuchardt
2021-01-07 12:36   ` Simon Glass
2021-01-18 13:02   ` Tom Rini
2021-01-04  7:02 ` [PATCH 2/5] log: make debug_cond() function like Heinrich Schuchardt
2021-01-07 12:36   ` Simon Glass
2021-01-18 13:02   ` Tom Rini
2021-01-04  7:02 ` [PATCH 3/5] log: provide missing macros Heinrich Schuchardt
2021-01-07 12:36   ` Simon Glass
2021-01-18 13:02   ` Tom Rini
2021-01-04  7:02 ` [PATCH 4/5] log: convert pr_*() to logging Heinrich Schuchardt
2021-01-07 12:36   ` Simon Glass
2021-01-17  0:16   ` Tom Rini
2021-01-17  7:37     ` Heinrich Schuchardt
2021-01-18 13:02       ` Tom Rini
2021-01-18 15:30         ` Tom Rini
2021-02-18  9:16           ` Heinrich Schuchardt
2021-02-18 13:05             ` Tom Rini
2021-02-18 15:04               ` Patrice CHOTARD [this message]
2021-01-17  0:37   ` Sean Anderson
2021-01-17  7:26     ` Heinrich Schuchardt
2021-01-17 22:27       ` Sean Anderson
2021-01-17 23:13         ` Heinrich Schuchardt
2021-03-02  3:47   ` Tom Rini
2021-01-04  7:02 ` [PATCH 5/5] test: unit test for pr_err(), pr_cont() Heinrich Schuchardt
2021-01-07 12:36   ` Simon Glass
2021-01-18 13:02   ` Tom Rini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5fdcee2-c112-197c-48ef-b74eb7132553@foss.st.com \
    --to=patrice.chotard@foss.st.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox