Re: regarding ata_msg_*()

[Tejun Heo <htejun@gmail.com>]

Jeff Garzik wrote:
> 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.

Yeap, agreed.

My point is that as we need selective message enabling, let's do it by 
first implementing 1:1 mapping and think about message types later.  As 
we already have ata_*_printk() wrappers, embedding ata_msg_*() and 
converting KERN_* to ATA_MSG_* should be enough.

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

Generally agreed.  I don't think your and my ideas are that different. 
Mine looks like..

ATA_MSG_ERR
ATA_MSG_WARNING
ATA_MSG_INFO	/* I think intial config msg should be in this cat */
(ATA_MSG_VINFO maybe) /* revalidation messages, EH progress... */
-- debug below here
ATA_MSG_DEBUG
ATA_MSG_VDEBUG
ATA_MSG_CMD	/* issue / completion */
ATA_MSG_SG	/* SG map/unmap handling */
ATA_MGS_TRACE	/* function enter/exit */

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

Yeah, we really need that.  I currently use /dev/hda as my root when I 
need to turn on those debug messages.  :-P

-- 
tejun