Re: regarding ata_msg_*()

[Jeff Garzik <jgarzik@pobox.com>]

Tejun Heo wrote:
> ATA_MSG_ERR
> ATA_MSG_WARN
> ATA_MSG_INFO
> -------------> all above are enabled by default
> ATA_MSG_DEBUG
> ATA_MSG_VDEBUG


The current ATA_MSG_xxx were best-guesses, and only now, when the 
conversion patches begin to be merged, do we see how well those guesses 
match with reality.

I do agree that the above list matches the current code, but the 
ATA_MSG_xxx and Becker schemes are aimed more at verbosity+severity 
levels, than strictly severity levels.

<thinking aloud>  For libata, the best mapping might be

0: critical problems (errors)
1: non-critical, recovered problems or "troubling circumstances" (warnings)
2: terse info from exceptional events (probe, hotplug)
3: more verbose info about exceptional events (IDENTIFY hex values as 
shown today, sector count, features)
4: terse command-submit tracing
5: terse command-complete tracing
6: verbose hot path
7: function ENTER/EXIT tracing

Thus illustrating the general goals of (a) enabling fine-grained tracing 
of specific portions of libata, (b) ordering messages in order of 
severity, and (c) ordering messages by likelihood of producing tons of 
log spam.

Eventually we can use blktool to turn on terse command-complete tracing 
for a single SATA port, and not have to suffer the current log spam and 
coarseness that results from using today's #defines.

	Jeff