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
-
