U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH 4/5] log: convert pr_*() to logging
Date: Sun, 17 Jan 2021 08:26:24 +0100	[thread overview]
Message-ID: <8ff2f664-dbb0-04c7-a605-0839e0632ce1@gmx.de> (raw)
In-Reply-To: <b6f38619-3f80-4c54-ccaf-7d59c5078ea4@gmail.com>

On 1/17/21 1:37 AM, Sean Anderson wrote:
> On 1/4/21 2:02 AM, 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(-)
>>
>> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
>> index 16f28993f5..d2e5ca026e 100644
>> --- a/include/linux/bitops.h
>> +++ b/include/linux/bitops.h
>> @@ -6,7 +6,6 @@
>> ? #include <asm/types.h>
>> ? #include <asm-generic/bitsperlong.h>
>> ? #include <linux/compiler.h>
>> -#include <linux/kernel.h>
>>
>> ? #ifdef??? __KERNEL__
>> ? #define BIT(nr)??????????? (1UL << (nr))
>> @@ -19,6 +18,9 @@
>> ? #define BITS_TO_LONGS(nr)??? DIV_ROUND_UP(nr, BITS_PER_BYTE * 
>> sizeof(long))
>> ? #endif
>>
>> +/* kernel.h includes log.h which include bitops.h */
>> +#include <linux/kernel.h>
>> +
>> ? /*
>> ?? * Create a contiguous bitmask starting at bit position @l and 
>> ending at
>> ?? * position @h. For example
>> diff --git a/include/linux/printk.h b/include/linux/printk.h
>> index 088513ad29..5e85513853 100644
>> --- a/include/linux/printk.h
>> +++ b/include/linux/printk.h
>> @@ -1,6 +1,7 @@
>> ? #ifndef __KERNEL_PRINTK__
>> ? #define __KERNEL_PRINTK__
>>
>> +#include <log.h>
>> ? #include <stdio.h>
>> ? #include <linux/compiler.h>
>>
>> @@ -28,49 +29,56 @@
>> ????? 0;??????????????????????? \
>> ? })
>>
>> -#define __printk(level, fmt, ...)??????????????????? \
>> -({??????????????????????????????????? \
>> -??? level < CONFIG_LOGLEVEL ? printk(fmt, ##__VA_ARGS__) : 0;??? \
> 
> Couldn't we just do
> 
> #define __printk(level, fmt, ...) log(LOG_CATEGORY, level, fmt, 
> ##__VA_ARGS__)

Dear Sean,

Thanks for reviewing.

As of today log() does not print anything if CONFIG_LOG is not enabled.

A patch by Simon to change this behavior is pending. If it gets merged, 
we can do the suggested simplification.

log: Convert log values to printf() if not enabled
https://patchwork.ozlabs.org/project/uboot/patch/20210114033051.483560-5-sjg at chromium.org/

> 
>> -})
>> -
>> ? #ifndef pr_fmt
>> ? #define pr_fmt(fmt) fmt
>> ? #endif
>>
>> -#define pr_emerg(fmt, ...) \
>> -??? __printk(0, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_alert(fmt, ...) \
>> -??? __printk(1, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_crit(fmt, ...) \
>> -??? __printk(2, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_err(fmt, ...) \
>> -??? __printk(3, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_warning(fmt, ...) \
>> -??? __printk(4, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_warn pr_warning
>> -#define pr_notice(fmt, ...) \
>> -??? __printk(5, pr_fmt(fmt), ##__VA_ARGS__)
>> -#define pr_info(fmt, ...) \
>> -??? __printk(6, pr_fmt(fmt), ##__VA_ARGS__)
>> -
>> -#define pr_cont(fmt, ...) \
>> -??? printk(fmt, ##__VA_ARGS__)
>> -
>> -/* pr_devel() should produce zero code unless DEBUG is defined */
>> -#ifdef DEBUG
>> -#define pr_devel(fmt, ...) \
>> -??? __printk(7, pr_fmt(fmt), ##__VA_ARGS__)
>> -#else
>> -#define pr_devel(fmt, ...) \
>> -??? no_printk(pr_fmt(fmt), ##__VA_ARGS__)
>> -#endif
>> +#define pr_emerg(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 0 ? log_emerg(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
> 
> There is also an off-by-one mismatch between the numbers here and the
> log level constants. E.g. LOGL_INFO is 6, but pr_info only gets emitted
> if CONFIG_LOGLEVEL is >= 7.

The Kconfig for CONFIG_LOGLEVEL description reads:

"All Messages with a loglevel *smaller than* the console loglevel will 
be compiled in."

I did not intend to change this definition.

Best regards

Heinrich

> 
> --Sean
> 
>> +#define pr_alert(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 1 ? log_alert(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
>> +#define pr_crit(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 2 ? log_crit(fmt, ##__VA_ARGS__) : 0;??????? \
>> +})
>> +#define pr_err(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 3 ? log_err(fmt, ##__VA_ARGS__) : 0;??????? \
>> +})
>> +#define pr_warn(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 4 ? log_warning(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
>> +#define pr_notice(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 5 ? log_notice(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
>> +#define pr_info(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 6 ? log_info(fmt, ##__VA_ARGS__) : 0;??????? \
>> +})
>> +#define pr_debug(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 7 ? log_debug(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
>> +#define pr_devel(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? CONFIG_LOGLEVEL > 7 ? log_debug(fmt, ##__VA_ARGS__) : 0;??? \
>> +})
>>
>> -#ifdef DEBUG
>> -#define pr_debug(fmt, ...) \
>> -??? __printk(7, pr_fmt(fmt), ##__VA_ARGS__)
>> +#ifdef CONFIG_LOG
>> +#define pr_cont(fmt, ...)??????????????????????? \
>> +({??????????????????????????????????? \
>> +??? gd->logl_prev < CONFIG_LOGLEVEL ???????????????? \
>> +??????? log_cont(fmt, ##__VA_ARGS__) : 0;??????????? \
>> +})
>> ? #else
>> -#define pr_debug(fmt, ...) \
>> -??? no_printk(pr_fmt(fmt), ##__VA_ARGS__)
>> +#define pr_cont(fmt, ...)??????????????????????? \
>> +??? printk(fmt, ##__VA_ARGS__)
>> ? #endif
>>
>> ? #define printk_once(fmt, ...) \
>> -- 
>> 2.29.2
>>
> 

  reply	other threads:[~2021-01-17  7:26 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
2021-01-17  0:37   ` Sean Anderson
2021-01-17  7:26     ` Heinrich Schuchardt [this message]
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=8ff2f664-dbb0-04c7-a605-0839e0632ce1@gmx.de \
    --to=xypron.glpk@gmx.de \
    --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