Re: regarding ata_msg_*()

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