[lkml]   [2007]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] New kernel-message logging API
    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

    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:

    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

    Kyle Moffett

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-09-23 05:47    [W:0.042 / U:9.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site