Re: Event logging vs enhancing printk

[Martin J. Bligh]

>> The current printk simply does not cut it for these applications. There are
>> over 80000 printk statements in the kernel, using many different conventions.
> 
> It would be easier, to fix the printk's, than to put evlogging into any
> particular piece of the kernel.

You want to fix 80000 printks? Be my guest ... I await your patch eagerly.
If you mean changing printk with a wrapper to help clean up the existing
mess in an automated fashion, that's exactly what's being proposed.

> Evlog side-by-side with printk adds significat bloat.

To what? A kernel with event logging switch on? Sure. 
But if you don't want it, don't turn it on. If it's a config option, I don't
see why anyone would care.
 
> What I hear you asking for, is to make it more of
> the kernels responsibilty easing the problem of analysing the out put,
> as opposed to making that the responsibilty of user space
> postprocessing. 

Indeed. That's because the kernel has more context, and can trivially
log the information it has, rather then reverse engineering it from user space.
Why munge all the messages to post them through a tiny little formatting
hole, and then try to unmunge them all again on the other side with a
bunch of hokey scripts?

> One thing to keep in mind, 99% of logged messages will
> never be reviewed.

If we had a more structured log format, it'd be a damned sight easier to
write automated tools to parse through them, and actually do something
useful with that 99%. Been there, done that.
 
> But poorly implemented, a new format will in pratice increase the
> volume, and with the increased complexity of the logging also slowing
> down, logging will be slower, and more messages will be lost.  This has
> been seen in pratice.

But correctly implemented, it will help. That's why this is being debated in
public to make sure the design is correct.

> I would prefer to see effort expended on fixing printk/klogd...off the
> top of my head:
> 
> - make printk a macro that prepends file/function/line to the message.
> - fix printk calls: messages with consistent format, calls in the right
> places, with the "correct" information.
> - postprocessing tools for analysing the logs.

This is actually very close to what is being proposed. The main reason the
we came to the conclusion that end result should be dumped into an evlog
file instead of dmesg and /var/log/messages is that changing the format
of /var/log/messages breaks the existing log parsing tools that people have.

If people wanted to take the improvments made for event logging, and use
those to change the dmesg output format, that would be a fairly simple efffort
for them to do as an additional patch on top of event logging.

M.