archive mirror
 help / color / mirror / Atom feed
From: John Ogness <>
To: Masahiro Yamada <>,, Petr Mladek <>,
	Sergey Senozhatsky <>,
	Steven Rostedt <>
Cc: Masahiro Yamada <>,
	Andy Shevchenko <>,
	Ard Biesheuvel <>, Borislav Petkov <>,
	Darren Hart <>,
	Dimitri Sivanich <>,
	Greg Kroah-Hartman <>,
	"H. Peter Anvin" <>, Ingo Molnar <>,
	Jiri Slaby <>,
	Mike Travis <>,
	Peter Jones <>,
	Russ Anderson <>,
	Steve Wahl <>,
	Thomas Gleixner <>,,,,,
Subject: Re: [PATCH 1/3] printk: use CONFIG_CONSOLE_LOGLEVEL_* directly
Date: Tue, 02 Feb 2021 09:44:22 +0106	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2021-02-02, Masahiro Yamada <> wrote:
> CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of
> When you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from Kconfig, almost
> all objects are rebuilt because CONFIG_CONSOLE_LOGLEVEL_DEFAULT is
> used in <linux/printk.h>, which is included from most of source files.
> In fact, there are only 4 users of CONSOLE_LOGLEVEL_DEFAULT:
>   arch/x86/platform/uv/uv_nmi.c
>   drivers/firmware/efi/libstub/efi-stub-helper.c
>   drivers/tty/sysrq.c
>   kernel/printk/printk.c
> So, when you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT and rebuild the
> kernel, it is enough to recompile those 4 files.
> Remove the CONSOLE_LOGLEVEL_DEFAULT definition from <linux/printk.h>,

With commit a8fe19ebfbfd ("kernel/printk: use symbolic defines for
console loglevels") it can be seen that various drivers used to
hard-code their own values. The introduction of the macros in an
intuitive location (include/linux/printk.h) made it easier for authors
to find/use the various available printk settings and thresholds.

Technically there is no problem using Kconfig macros directly. But will
authors bother to hunt down available Kconfig settings? Or will they
only look in printk.h to see what is available?

IMHO if code wants to use settings from a foreign subsystem, it should
be taking those from headers of that subsystem, rather than using some
Kconfig settings from that subsystem. Headers exist to make information
available to external code. Kconfig (particularly for a subsystem) exist
to configure that subsystem.

But my feeling on this may be misguided. Is it generally accepted in the
kernel that any code can use Kconfig settings of any other code?

John Ogness

  reply	other threads:[~2021-02-02  8:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-02  7:02 [PATCH 1/3] printk: use CONFIG_CONSOLE_LOGLEVEL_* directly Masahiro Yamada
2021-02-02  8:38 ` John Ogness [this message]
2021-02-03 15:23   ` Petr Mladek
2021-02-03 21:51     ` Masahiro Yamada
2021-02-04 10:16       ` Petr Mladek
2021-02-02 10:09 ` Sergey Senozhatsky
2021-02-02 23:04   ` Masahiro Yamada
2021-02-02 10:12 ` Greg Kroah-Hartman

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).