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

[Jean Delvare]

Hi Joe,

On Wed, 08 Aug 2007 15:21:53 -0700, Joe Perches wrote:
> On Wed, 2007-08-08 at 23:57 +0200, Jan Engelhardt wrote:
> > fs/freevxfs/vxfs_bmap.c:line 169 (near "case VXFS_TYPED_DATA_DEV4")
> > 
> >                         printk(KERN_INFO "\n\nTYPED_DEV4 detected!\n");
> > Seems normal.
> 
> The second output log line of the first printk isn't prefixed
> with KERN_INFO.  It's output with log_level_unknown.

True. This simply means that the leading \n's shouldn't be there.
Pretty easy to fix.

> > So it looks like your regex has some false positives.
> > (which nothing can be done about - the 61 must be hand-sorted)
> 
> Must have copy/pasted the wrong regex
> 
> $ egrep -r "printk[[:space:]]*\([[:space:]]*KERN.*\\\n[A-JL-Za-jl-z[:space:]]" --include=*.[ch] * | wc -l
> 61
> 
> > [My idea is above]
> 
> Any sequence of printks can be interleaved.  I don't see
> how your suggestion changes that.
> 
> > >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.
> > 
> > How is this supposed to work? Are you suggesting that the printk buffer is
> > locked?
> 
> No, just another identifier placed into logs that allow messages
> to be reassembled into something readable when multiple printk_block's
> are active.
> 
> > Now, if you hold the output of a printk block until it's _end()
> > counterpart is executed, the user does not get any output when the
> > machine locks up during the for loop.
> 
> External tool scans logs.  No blocking or delay in output.

Assuming that the related messages are prefixed in a similar way (as
dev_info and friends do), grouping them is already possible, and pretty
trivial: grep can select whatever you are interested in.

I'm not saying that your ideas are all bad. The ability to build a
kernel without the least interesting messages is valuable. Having a
more standard formatting for log messages is interesting as well,
although dev_info and friends already offer this to some extent. But
you have to realize that kernel logging must stay something very
simple, and that the first tool to read them is "dmesg" and not some
funky log scanner. So the current implementation can't be that far from
what we need.

Thanks,
-- 
Jean Delvare
-
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/