On Saturday, September 22, 2007 12:27 pm Vegard Nossum wrote:
> enum kprint_loglevel {
> KPRINT_EMERG, /* kprint_emerg() */
> KPRINT_ALERT, /* kprint_alert() */
> KPRINT_CRIT, /* kprint_crit() */
> KPRINT_ERROR, /* kprint_error() and/or kprint_err() */
> KPRINT_WARNING, /* kprint_warning() and/or kprint_warn() */
> KPRINT_NOTICE, /* kprint_notice() */
> KPRINT_INFO, /* kprint_info() */
> KPRINT_DEBUG, /* kprint_debug() */
> };
I wonder if all these levels are still needed (though I really like the
error/err & warning/warn aliases, those always get me :).
It seems like fewer levels would make things easier on both kernel
developers and administrators; looking at current counts may help
figure out which ones could be combined (warning, very naive grep -r
data):
KERN_EMERG: 371
KERN_ALERT: 236
KERN_CRIT: 602
KERN_ERR: 11961
KERN_WARNING: 6463
KERN_NOTICE: 1142
KERN_INFO: 8491
KERN_DEBUG: 6125
So KERN_ERR is the most common by a pretty large margin, though it seems
to me that KERN_NOTICE, KERN_INFO and KERN_DEBUG are mostly redundant
and probably make up a majority of the "SIMD FPU exception support was
enabled" (as if I care) type messages. Likewise, ERR, ALERT, CRIT and
EMERG serve very similar purposes (i.e. something unrecoverable
occurred), maybe they could be condensed into one or two levels rather
than four? So that would drop us to three levels:
KERN_ERR /* something really bad happened, machine is dead or near so */
KERN_WARNING /* you really ought to know about this */
KERN_INFO /* no one but the kernel developer likely cares about this */
But maybe I'm just living in a dream world where then number of printks
the kernel spits out suddenly drops by 99% and only actually important
messages make it to my log...
Jesse
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
