[cgl_discussion] Re: [evlog-dev] alternate event logging proposal
Daniel E. F. Stekloff
dsteklof at us.ibm.com
Tue Sep 24 13:54:38 PDT 2002
On Tuesday 24 September 2002 12:48 pm, Jeff Garzik wrote:
> 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.
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
We propose standardizing what should be logged and how those log messages
- Drivers should log initialization and uninitialization information for both
drivers and devices. Knowning when a driver is loaded or unloaded is useful
- 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
- Errors during operation should be logged.
- 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
- Use defined severity levels.
- Make sure that consitent logging and terminology is used throughout the
Most of what I just outlined is common sense, but it's worth stating.
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> evlog-developers mailing list
> evlog-developers at lists.sourceforge.net
More information about the cgl_discussion