Messages in this thread | | | Date | Tue, 11 Oct 2016 23:05:56 -0300 | From | Mauro Carvalho Chehab <> | Subject | Re: fyi: Recent commits require printk("fmt", ...) -> printk(PR_CONT/pr_cont( conversions |
| |
Em Tue, 11 Oct 2016 18:29:42 -0700 Joe Perches <joe@perches.com> escreveu:
> Linus merged this recently (unfortunately without cc'ing LKML) > > ---------------------------------------------------------------------------- > commit 563873318d328d9bbab4b00dfd835ac7c7e28697 > Merge: 24532f768121 bfd8d3f23b51 > Author: Linus Torvalds <torvalds@linux-foundation.org> > 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.c > mm/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.
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
| |