From: Chris Down <chris@chrisdown.name>
To: Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org, Jessica Yu <jeyu@kernel.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
John Ogness <john.ogness@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Kees Cook <keescook@chromium.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
kernel-team@fb.com
Subject: Re: [PATCH v6 3/4] printk: Userspace format indexing support
Date: Fri, 4 Jun 2021 12:50:05 +0100 [thread overview]
Message-ID: <YLoTbQjQzrPcLcHd@chrisdown.name> (raw)
In-Reply-To: <YLn+IEf3iEZpEeQZ@alley>
Petr Mladek writes:
>> Petr Mladek writes:
>> > Note that we do not store the value defined by pr_fmt() which
>> > is yet another automatically added prefix.
>>
>> Hmm, we do actually store pr_fmt, since it's known at compile time (or we
>> wouldn't store it at all if it was dynamic due to the __builtin_constant_p
>> check). Or are you seeing something different?
>
>I see. Well, the prefix defined by pr_fmt() becomes part of entry.fmt.
>It is _not_ stored in entry.pre_fmt which confused me.
>
>As I mentioned in the previous mail. I think about using "subsys_fmt"
>or "subsys_prefix" instead of "pre_fmt".
>
>Anyway, we should improve the comment. For example, something like:
>
> /*
> * The format string used by various subsystem specific printk()
> * wrappers to prefix the message.
> *
> * Note that the static prefix defined by pr_fmt() macro is handled
> * another way. It is stored directly in the message format (@fmt).
> */
> const char *subsys_fmt;
Sounds totally reasonable, will do.
>> > Is is possible to update __printk_index_emit() to do not create
>> > entries with fmt = NULL ?
>> >
>> > We should either remove the above check or add a comment
>> > explaining why it is necessary.
>>
>> The trick is unfortunately necessary for the reason described in the comment
>> above the double check:
>>
>> /*
>> * The compiler may not be able to eliminate the
>> * non-constant variants of _fmt and _level, so we need
>> * to make sure that it doesn't see any hypothetical
>> * assignment for non-constants even though this is
>> * already inside the __builtin_constant_p guard.
>> */
>>
>> Happy to add another comment if it helps.
>
>I re-read the discussion about this,
>namely https://lore.kernel.org/r/3Kf896Zt9O+/Yh@chrisdown.name
>
>Frankly, the comment above ftrace_vprintk() is easier to understand
>for me. I mean:
>
>/*
> * The double __builtin_constant_p is because gcc will give us an error
> * if we try to allocate the static variable to fmt if it is not a
> * constant. Even with the outer if statement.
> */
Oh yes, that does sound more clear. I'll update it :-)
Thanks!
next prev parent reply other threads:[~2021-06-04 11:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 12:00 [PATCH v6 0/4] printk: Userspace format indexing support Chris Down
2021-05-18 12:00 ` [PATCH v6 1/4] string_helpers: Escape double quotes in escape_special Chris Down
2021-05-18 13:10 ` Andy Shevchenko
2021-05-18 14:10 ` Chris Down
2021-05-25 10:17 ` Petr Mladek
2021-05-18 12:00 ` [PATCH v6 2/4] printk: Straighten out log_flags into printk_info_flags Chris Down
2021-05-25 10:33 ` Petr Mladek
2021-05-25 11:35 ` John Ogness
2021-05-26 7:31 ` Petr Mladek
2021-05-26 8:39 ` John Ogness
2021-05-26 9:25 ` Petr Mladek
2021-06-01 15:16 ` Chris Down
2021-05-18 12:00 ` [PATCH v6 3/4] printk: Userspace format indexing support Chris Down
2021-05-18 13:30 ` Andy Shevchenko
2021-05-18 14:07 ` Chris Down
2021-05-18 16:00 ` Andy Shevchenko
2021-05-18 16:28 ` Chris Down
2021-05-18 16:59 ` Chris Down
2021-05-19 6:59 ` Rasmus Villemoes
2021-05-20 9:25 ` Andy Shevchenko
2021-05-25 15:19 ` Petr Mladek
2021-05-25 15:06 ` Petr Mladek
2021-06-01 15:15 ` Chris Down
2021-06-04 10:19 ` Petr Mladek
2021-06-04 11:50 ` Chris Down [this message]
2021-05-18 12:00 ` [PATCH v6 4/4] printk: index: Add indexing support to dev_printk Chris Down
2021-05-26 8:57 ` Petr Mladek
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=YLoTbQjQzrPcLcHd@chrisdown.name \
--to=chris@chrisdown.name \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jeyu@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
/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