Re: + remove-current-defines-and-uses-of-pr_err-add-pr_emerg.patchadded to -mm tree

[Joe Perches]

On Wed, 2007-08-08 at 22:39 +0200, Jan Engelhardt wrote:
> I fail to see what problem these are trying to fix. 

Any code that does the equivalent of printk(KERN_foo "\n message");

egrep -r "printk[[:space:]]*\([[:space:]]*KERN.*\\\n[A-JL-Za-jl-z[:space:]" --include=*.[ch] *

At least 61 instances right now.

> Please post some broken code that would 'benefit' from pr_halleluja,
> and why printk(level ) could not do the same.

"Could" most always leads to an interesting argument.

Future minimization of introduced error is a benefit
not an absolute.

Adding the ability to log higher priority KERN_<level>
without removing printk altogether for embedded systems
seems useful.  You could leave out say just KERN_INFO,
KERN_NOTICE and KERN_WARN levels.

Worth the churn is another question, though git seems to
allow most everyone to resync to tree wide changes pretty
easily.

If new pr_<level> defines aren't accepted, I suggest
removing the current ~200 uses of pr_info.

> >8 Minimization/elimination of interleaved log messages
> 
> This is a separate, and worthwhile, thing to do, yes.
> And it can be done without deviating from the regular printk().

I'm not sure how.  Maybe you have an idea you could share?

Maybe an external tool to reassemble complete messages from
prefixed {{cookie}} message logs would be fine for awhile.

Perhaps something like:

cookie = printk_block_start()
printk_block[s](cookie)
printk_block_end(cookie)?

where printk_block emits cookie when multiple cookies
are active.

cheers,  Joe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/