Re: [Announce] Linux-tiny project revival

[Joe Perches <joe@perches.com>]

On Thu, 2007-09-20 at 19:28 -0500, Rob Landley wrote:
> You convert printk(KERN_INFO, blah) to pr_INFO(blah)?

more or less.
printk(KERN_INFO foo) to pr_info(foo)
printk(KERN_EMERG foo) to pr_emerge(foo)
etc.

> I'm not finding pr_INFO with a grep on the files in 
> 2.6.23-rc7.

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