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