Re: [RFC] New kernel-message logging API

From: Kyle Moffett
Date: Sat Sep 22 2007 - 23:52:04 EST


On Sep 22, 2007, at 20:47:21, Joe Perches wrote:
On Sat, 2007-09-22 at 20:40 -0400, Kyle Moffett wrote:
Severity is *exactly* "desirability of logging".

Disagree.

What's info to someone is an alert to someone else. The problem is the valuation of the reasoning.

It's all opinion.

For starters, I think "its all opinion" is bogus; the value of each log level is pretty standardly defined for the kernel:
EMERG: The system is completely failing right NOW. Immediate admin action is definitely required
ALERT: The system is about to fail or halfway-failing. Immediate admin action may be required.
ERR: Something went badly wrong. We are able to continue without endangering the overall system.
NOTICE: Something unusual happened but it's either not a device/code failure or it's an expected failure.
INFO: Something useful happened, like a device probe or a major system-wide event
DEBUG: Something happened that only a developer or somebody looking for bugs would care about.

All of those are basically defined as: "This is how much the admin probably wants to see this message". If you find a message which doesn't seem to match the log level it's logged at, please submit a patch.

Even assuming its not a bogus argument, what you actually want is *NOT* "Show me INFO and DEBUG, but not EMERG, ALERT, ERR, or NOTICE", you actually want multiple metrics by which to measure things. We already have multiple ways of filtering log messages:
1) Log-level (greater than $LEVEL).
2) Userspace textual post-processing filters and classifiers (EG: logcheck)
3) CONFIG_${SUBSYS}_DEBUG and CONFIG_${DRIVER}_DEBUG

Perhaps what you want is something like the syslog "facility" parameter?

The only real reason to add more kconfig options for logging is to decrease the size of the kernel binary; most anything else can be better done in userspace in something like logcheck. If you're going to add new kconfig options then you aren't going to configure them generically since they're inherently subsystem/driver specific. In that case you might add a per-driver "CONFIG_${DRIVER}_NOLOG" for the drivers you care about or a "CONFIG_MAX_LOG_LEVEL" to globally limit by severity but any other qualifiers inherently don't fit in a single scalar

Cheers,
Kyle Moffett

-
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/