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

Re: regarding ata_msg_*()

flat view

From: Borislav Petkov <hidden>
Date: 2006-06-26 08:35:03

On Mon, Jun 26, 2006 at 05:00:39PM +0900, Tejun Heo wrote:

Hi Tejun,

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

Regards,
    Boris.

		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help