Re: [PATCH] printk: Userspace format enumeration support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joe Perches writes:
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.

Hmm, that's just a manifestation of directly using `shuf` without doing the transformation of trailing nulls to newlines shown in the changelog. They are still distinct and separated by nulls.

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);

There are certainly printks which can't be trivially monitored using the printk format alone, but the vast majority of the ones that are monitored _do_ have meaningful formats and can be monitored over time. No solution to this is going to catch every single case, especially when so much of the information can be generated dyamically, but this patchset still goes a long way to making printk monitoring more tractable for use cases like the one described in the changelog.



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux