Cc: Tim Bird <tim.bird@...>, <linux-tiny@...>, linux kernel <linux-kernel@...>, CE Linux Developers List <celinux-dev@...>, Michael Opdenacker <michael@...>
On Thu, 2007-09-20 at 19:28 -0500, Rob Landley wrote:
more or less.
printk(KERN_INFO foo) to pr_info(foo)
printk(KERN_EMERG foo) to pr_emerge(foo)
etc.
I haven't submitted them.
There's a lot of sensible resistance to what appears
to be churn. Some of the resistance is historical,
merging large changes used to be much more painful
pre git, some is just simple resistance to change.
I started with submitting an add of pr_err to kernel.h
which Andrew Morton picked up for awhile, but dropped.
I've got a local tree with those changes.
for example:
KERN_EMERG -> pr_emerg is ~100KB
KERN_ALERT -> pr_alert is ~80KB
KERN_CRIT -> pr_crit is ~200KB
KERN_NOTICE -> pr_notice is ~400KB
KERN_INFO -> pr_info is ~2500KB
I intended to strip the "\n" trailer from the messages.
Back to the scripts:
In this case, there are multiple files.
A script that finds all the files that contain a search string,
and a perl script that effectively s/search/replace/g on those files.
sed didn't work as well as perl here because I wanted to
play with perl a bit and many printk(KERN_<level> foo)
function calls are split across multiple lines.
I've still got to show a real use to this change set.
I believe controlling the interleaving of log messages
by having multiple statement printks have a start and end,
choosing specific message levels in compiled code,
and choosing to print file/function/line per compiled
code block might do, but more utility to the changes
is probably necessary before it could be applied.
cheers, Joe
-
