Thread (7 messages) 7 messages, 3 authors, 2006-06-27

Re: regarding ata_msg_*()

flat view

From: Tejun Heo <hidden>
Date: 2006-06-27 03:23:37

Borislav Petkov wrote:
quoted
My suggestion is to keep the current (pre-msg_enable) model for the first conversion and categorize debug messages further after that.  So, message categories will be...

ATA_MSG_ERR
ATA_MSG_WARN
ATA_MSG_INFO
-------------> all above are enabled by default
ATA_MSG_DEBUG
ATA_MSG_VDEBUG

Then, you have 1-to-1 mapping w/ the existing messages.  You can simply incorporate message enabled tests into ata_*_printk() functions and the conversion would be trivial.

After that's complete, we can diversify ATA_MSG_DEBUG and ATA_MSG_VDEBUG by separating out chatty ones out.  e.g. you can separate out SG mapping/unmapping (including padding) debug messages, which produce massive amount of logs when enabled, into ATA_MSG_SG or something. After several such separations, debug messages should be quite manageable && the categories wouldn't be too elaborate.
Yes, this sounds logical, I like it, it really fits libata more but at the time
I made that msg classification I kinda wanted to stick closely to Becker's
initial implementation :). But you're perfectly right, this is the way to go so
I'll do that after reading what the others have to say. However, as I said
before, IMHO it would be of higher priority now to convert to this new scheme
and changing the dbg levels later would be trivial once we got all of libata
done.
Jeff, what do you think?

Borislav, can you restore configuration messages in ata_dev_configure()?  Those messages need to be printed.

Thanks.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help