fyi: Recent commits require printk("fmt", ...) -> printk(PR_CONT/pr_cont( conversions
Linus merged this recently (unfortunately without cc'ing LKML)
----------------------------------------------------------------------------
commit 563873318d328d9bbab4b00dfd835ac7c7e28697
Merge: 24532f768121 bfd8d3f23b51
Author: Linus Torvalds <[email protected]> Date: Mon Oct 10 09:29:50 2016 -0700
Merge branch 'printk-cleanups'
Merge my system logging cleanups, triggered by the broken '\n' patches.
The line continuation handling has been broken basically forever, and the code to handle the system log records was both confusing and dubious. And it would do entirely the wrong thing unless you always had a terminating newline, partly because it couldn't actually see whether a message was marked KERN_CONT or not (but partly because the LOG_CONT handling in the recording code was rather confusing too).
This re-introduces a real semantically meaningful KERN_CONT, and fixes the few places I noticed where it was missing. There are probably more missing cases, since KERN_CONT hasn't actually had any semantic meaning for at least four years (other than the checkpatch meaning of "no log level necessary, this is a continuation line").
----------------------------------------------------------------------------
These changes are not bad as they allow a message to remove the now unnecessary terminating newline or not have the newline added in the first place. But there is also a modified behavior to existing logging message code.
Given the new behavior of bare printk that continues a line now requires a PR_CONT. There are several places that will need update to have the same logging output as before this series.
For instance:
fs/ext4/super.cmm/page_alloc.c
And many files in these directories:
drivers/media/drivers/gpu/drivers/block/
and other directories as well.'
Many drivers for ancient and out of production hardware, and the old, crufty, and unmaintained drivers also have this issue, but likely no one will be impacted by this change to those driver's logging code.
Em Tue, 11 Oct 2016 18:29:42 -0700
Joe Perches <[email protected]> escreveu:
Quoted 47 lines
Linus merged this recently (unfortunately without cc'ing LKML)
----------------------------------------------------------------------------
commit563873318d328d9bbab4b00dfd835ac7c7e28697
Merge:24532f768121bfd8d3f23b51
Author: Linus Torvalds <[email protected]> Date: Mon Oct 10 09:29:50 2016 -0700Merge branch 'printk-cleanups'
Merge my system logging cleanups, triggered by the broken '\n' patches.
The line continuation handling has been broken basically forever, and the code to handle the system log records was both confusing and dubious. And it would do entirely the wrong thing unless you always had a terminating newline, partly because it couldn't actually see whether a message was marked
KERN_CONTor not (but partly because theLOG_CONThandling in the recording code was rather confusing too).This re-introduces a real semantically meaningful
KERN_CONT, and fixes the few places I noticed where it was missing. There are probably more missing cases, sinceKERN_CONThasn't actually had any semantic meaning for at least four years (other than the checkpatch meaning of "no log level necessary, this is a continuation line").
----------------------------------------------------------------------------These changes are not bad as they allow a message to remove the now unnecessary terminating newline or not have the newline added in the first place. But there is also a modified behavior to existing logging message code.
Given the new behavior of bare printk that continues a line now requires a
PR_CONT. There are several places that will need update to have the same logging output as before this series.For instance:
fs/ext4/super.cmm/page_alloc.cAnd many files in these directories:
drivers/media/drivers/gpu/drivers/block/
Quoted 5 lines
and other directories as well.'
Many drivers for ancient and out of production hardware, and the old, crufty, and unmaintained drivers also have this issue, but likely no one will be impacted by this change to those driver's logging code.
Thanks for warning! Yeah, there are lots of media drivers written before we start using KERN_CONT for continuation on media. On a rough estimation, I'd say we have about 100 drivers with such stuff:
$ git grep -E '\bprintk' drivers/media/|grep -v KERN_|grep -v '\\n'|cut -d: -f1|sort|uniq|wc -l 97
But the above grep doesn't catch things like:
printk(DRIVER_NAME ": Device must be connected to a high-speed" " USB 2.0 port.\n");
(with should actually be calling pr_info instead of printk)
Yet, there are a lot of drivers to check.
Thankfully, most (if not all) of KERNEL_CONT cases are used for debugging purposes. So, normal users shouldn't notice it.
I'll seek for some time to review it, at least on the most used drivers.
Thanks,
Mauro