linux-kernel - Re: [PATCH v3] omap: dmtimer: convert printk to pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 Oct 2011 20:57:14 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Joe Perches <joe@...ches.com>
Cc:	Víctor Manuel Jáquez Leal 
	<vjaquez@...lia.com>, Tony Lindgren <tony@...mide.com>,
	linux-kernel@...r.kernel.org,
	Timo Teras <timo.teras@...idboot.com>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3] omap: dmtimer: convert printk to pr_err

On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote:
> On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote:
> > On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
> > > At some point in the next couple of years, I want
> > > to convert all of, or as many as possible of, the
> > > remaining printk uses to pr_<level>.
> > If the idea is also to get rid of printk() too (which IMHO would be a
> > good thing as it kills off the constant need to continually patch for
> > missing KERN_ prefixes) then that's a good reason (provided Linus
> > accepts the idea.)
> 
> I don't accept that idea yet.
> 
> There are about 50K printks vs 20K pr_<level>s
> in kernel source.
> 
> I think 50K lines is _way_ too many to convert
> in a couple of years.
> 
> I think it needs to be done subsystem by subsystem,
> arch by arch, as maintainers accept.

Agreed - but doing one instance here, maybe another instance somewhere
else, and come the merge window having several of these patches
scattered around with no real coherent "this is what we're doing, and
its all done for this bit of the tree" kind of story is not the way to
do it.

It would be good to get core code done, or a sub-arch, and then say
"we're not accepting any patch which re-introduces the problem"...
It's a little late in the cycle for that now though.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/