Re: [RFC] New kernel-message logging API

[Kyle Moffett]

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/