alternate event logging proposal

[Jeff Garzik]

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 
logging.

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.

Comments?

	Jeff