[lkml]   [2002]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectalternate event logging proposal
    Here's my suggestion, which will maintain compatibility with 2.2 and 2.4 
    kernels, and require a -very- minimal kernel update, to support event

    When CONFIG_EVLOG is defined, printk outputs a tagged ASCII format:
    KERN_xxx, the format string (verbatim), and 0 or more argument values.
    Since this loses the argument tags (names) from the current IBM event
    logging code, you can re-gain this info by post-processing the printk.
    Post-processing can be done by a hacked cpp (see
    for a tiny, steal-able one) or a simple Perl script.

    The only real difference at that point between IBM's implementation and
    my proposal is that some argument tags are expressions, not simple C
    identifiers (flag ? "true" : "false") instead of "flag". This is a
    problem if you want to do SQLish queries on the tags in the event log,
    but its a work-around-able problem, IMO.

    This scheme should fit with the backend code already created by IBM,
    which isn't too bad IMO.

    Even if the details are disagreeable, I really think that we should work
    towards making printk (or 'warn', 'error', etc.) log the desired
    information, while still keeping older drivers useful, and keeping
    drivers source-compatible with older kernels.

    Now, turning to a tangent topic that relates to either scheme...

    With either your proposal or mine, event logging is far more useful if
    similar drivers spit out similar diagnostics. i.e. it's less useful if
    8139too net driver spits out 'status16' in one interrupt event, and
    8139cp net driver spits out 'status32' in another. Though they are
    different hardware and the values mean different things, my point is the
    concepts are similar, and thus better diagnostics are achieved with
    subsystem diagnostic standards.

    Such standards are in actuality independent of event logging per se, but
    if IBM wants to push this thing, I would like to see some proposals as
    to what IBM actually wants drivers to log. I have not seen that at all,
    and think that such proposals should be an integral part of an event
    logging system. Otherwise the diagnostics are less useful, and IBM
    would have failed to demonstrate an adequate grasp of the problem domain
    [which then leads to other, typical software engineering problems...]

    "What do you want to log?" is as important to me as "how do you want to
    log it?" And the answers to the two questions are very much intertwined.



    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: 2005-03-22 13:29    [W:0.022 / U:8.296 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site