> >
> > > 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.
I take this one back, file/function/line does not add any useful
information to the vast majority of the printk messages, but adds a
great deal of bloat to the logs.
I think establishing some guide lines for log message content and
format, and updating some of the more critical parts of the kernel would
do a lot more to provide the kind of logging that is being called for.
It may well be that this needs to be done in a way that can be
controlled by a compile time option so the old format can be had by
those who prefer it, and the new by those who feel the need.
The basic problem, in my experience, is not the logging mechanisims, but
that the correct messages are not produced under the correct
conditions. This is a problem that can only be fixed by adding the
appropriate calls to whatever logging mechanism is available.
That is to say that, not all conditions that are critical are logged in
a way that provides the information to determine, after the fact, what
happened. A new logging mechanism will not fix that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/