From: Joe Perches <joe@perches.com>
To: Chris Down <chris@chrisdown.name>, Petr Mladek <pmladek@suse.com>
Cc: linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
John Ogness <john.ogness@linutronix.de>,
Johannes Weiner <hannes@cmpxchg.org>,
Andrew Morton <akpm@linux-foundation.org>,
kernel-team@fb.com, Steven Rostedt <rostedt@goodmis.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jason Baron <jbaron@akamai.com>,
Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org
Subject: Re: [PATCH] printk: Userspace format enumeration support
Date: Sat, 06 Feb 2021 09:57:00 -0800 [thread overview]
Message-ID: <49124db60cdc88c4e9fcca1bbc9767432ad5a93b.camel@perches.com> (raw)
In-Reply-To: <YB3Fwh827m0F+y3n@chrisdown.name>
On Fri, 2021-02-05 at 22:25 +0000, Chris Down wrote:
> Petr Mladek writes:
> > + <module> is already optinaly added by pr_fmt() to the printed strings
> > as: pr_fmt(): ...
>
> pr_fmts are not consistently used across the kernel, and sometimes differ from
> the module itself. Many modules don't use it at all, and we also don't have it
> for pr_cont. Just picking some random examples:
>
> % grep -av vmlinux /proc/printk_formats | shuf -n 10
> mac80211,6%s: mesh STA %pM switches to channel requiring DFS (%d MHz, width:%d, CF1/2: %d/%d MHz), aborting
> thinkpad_acpi,c N/Athinkpad_acpi,c %dthinkpad_acpi,5thinkpad_acpi: temperatures (Celsius):thinkpad_acpi,3thinkpad_acpi: Out of memory for LED data
I don't understand this format.
"Out of memory for LED data" is a single printk ending with a '\n' newline
I expected this to be broken up into multiple lines, one for each printk
that endsd in a newline.
And what would happen if the function was refactored removing the pr_cont
uses like the below: (basically, any output that uses a mechanism that
aggregates a buffer then emits it, and there are a _lot_ of those)
printk("%s\n", buffer);
And there is already a relatively trivial way to do this using a modified
version of strings that looks for KERN_SOH[0-6], and if dynamic_debug is
enabled, look in the dynamic_debug section, either __verbose or __dyndbg
depending on the kernel version.
---
drivers/platform/x86/thinkpad_acpi.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c
index 18b390153e7f..ff1c09c600f8 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -6353,21 +6353,26 @@ static void thermal_dump_all_sensors(void)
{
int n, i;
struct ibm_thermal_sensors_struct t;
+ char output[256];
+ int len = 0;
n = thermal_get_sensors(&t);
if (n <= 0)
return;
- pr_notice("temperatures (Celsius):");
+ len += scnprintf(output + len, sizeof(output) - len,
+ "temperatures (Celsius):");
for (i = 0; i < n; i++) {
- if (t.temp[i] != TPACPI_THERMAL_SENSOR_NA)
- pr_cont(" %d", (int)(t.temp[i] / 1000));
+ if (t.temp[i] == TPACPI_THERMAL_SENSOR_NA)
+ len += scnprintf(output + len, sizeof(output) - len,
+ " N/A");
else
- pr_cont(" N/A");
+ len += scnprintf(output + len, sizeof(output) - len,
+ " %d", t.temp[i] / 1000);
}
- pr_cont("\n");
+ pr_notice("%s\n", output);
}
/* sysfs temp##_input -------------------------------------------------- */
next prev parent reply other threads:[~2021-02-06 17:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 15:37 Chris Down
2021-02-05 0:47 ` Chris Down
2021-02-05 14:26 ` Chris Down
2021-02-05 16:42 ` Petr Mladek
2021-02-05 17:47 ` Steven Rostedt
2021-02-05 22:45 ` Chris Down
2021-02-05 22:49 ` Steven Rostedt
2021-02-06 7:13 ` Greg Kroah-Hartman
2021-02-06 12:44 ` Chris Down
2021-02-05 22:25 ` Chris Down
2021-02-06 17:57 ` Joe Perches [this message]
2021-02-06 21:21 ` Chris Down
2021-02-07 4:41 ` Joe Perches
2021-02-07 14:13 ` Chris Down
2021-02-07 14:58 ` Joe Perches
2021-02-07 16:13 ` Chris Down
2021-02-07 16:53 ` Chris Down
2021-02-07 22:21 ` kernel test robot
2021-02-08 1:13 ` Chris Down
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=49124db60cdc88c4e9fcca1bbc9767432ad5a93b.camel@perches.com \
--to=joe@perches.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chrisdown.name \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jbaron@akamai.com \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®