|| ||Jeff Garzik <email@example.com>|
|| ||Rusty Russell <firstname.lastname@example.org>|
|| ||alternate event logging proposal|
|| ||Tue, 24 Sep 2002 15:48:19 -0400|
|| ||linux-kernel mailing list <email@example.com>,
Alan Cox <firstname.lastname@example.org>,
cgl_discussion mailing list <email@example.com>,
evlog mailing list <firstname.lastname@example.org>,
"ipslinux (Keith Mitchell)" <email@example.com>,
Linus Torvalds <firstname.lastname@example.org>,
Hien Nguyen <email@example.com>,
James Keniston <firstname.lastname@example.org>,
Mike Sullivan <email@example.com>|
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 http://www.tinycc.org/
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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/