Re: [evlog-dev] alternate event logging proposal

Daniel E. F. Stekloff (dsteklof@us.ibm.com)
Tue, 24 Sep 2002 13:54:38 -0700


On Tuesday 24 September 2002 12:48 pm, Jeff Garzik wrote:

[snip)

> 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.
>
> Comments?

I agree with you that there needs to be a strategy for what is logged by a
driver and how it is logged. We believe log analysis is an essential part of
diagnosing errors. Log messages, when generated consistently, could indicate
what drivers were loaded, when they were loaded, what their current version
is, and what errors they have encountered. How the messages are formatted,
whether they follow certain rules, can greatly aid User Space diagnostic
applications.

We propose standardizing what should be logged and how those log messages
should look.

What:

- Drivers should log initialization and uninitialization information for both
drivers and devices. Knowning when a driver is loaded or unloaded is useful
information.

- Initialization information should include name of the device, name of the
driver, and the current version or release levels. Any errors encountered
during initialization - e.g. from running self tests - should be properly
logged.

- Errors during operation should be logged.

How:

- Messages should be human readable.

- Messages should be succinct.

- Messages should uniquely identify the driver and the device, such as many
drivers already do by prefixing messages with the driver name.

- Beware of log pollution - log only relevant information. Avoid frequently
recurring messages.

- Use defined severity levels.

- Make sure that consitent logging and terminology is used throughout the
driver.

Most of what I just outlined is common sense, but it's worth stating.

Any comments?

Dan

> Jeff
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> evlog-developers mailing list
> evlog-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/evlog-developers

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/