[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161011230556.6afe2764@vento.lan>
Date: Tue, 11 Oct 2016 23:05:56 -0300
From: Mauro Carvalho Chehab <mchehab@...pensource.com>
To: Joe Perches <joe@...ches.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Theodore Ts'o <tytso@....edu>
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@...ches.com> escreveu:
> Linus merged this recently (unfortunately without cc'ing LKML)
>
> ----------------------------------------------------------------------------
> commit 563873318d328d9bbab4b00dfd835ac7c7e28697
> Merge: 24532f768121 bfd8d3f23b51
> Author: Linus Torvalds <torvalds@...ux-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
Powered by blists - more mailing lists