On Fri, Jun 30, 2006 at 02:03:11AM +0900, Tejun Heo wrote:
<snip>
> Hello,
>
> I think this patchset is looking good generally. Please consider the
> following.
>
> * Don't make currently visible-by-default messages invisible-by-default
> or vice-versa.
The way I see it, we print by default everything marked ERR/WARN/DRV, as it is
being done down in libata-core.c
> * Don't mix visiable-by-default messages with debug messages. e.g. It
> seems you made ATA_MSG_INFO debug category and put EH messages and some
> debug messages into it. This is not good. EH messages should be
> visible to user by default && enabling it shouldn't turn on debug
> messages with it.
Well, it is sometimes unclear what level exactly a message should be but afterwe
have converted everything changing the level is as trivial as changing the
ATA_MSG_* arg passed to ata_(port/dev)_printk so this won't be a problem. An
initial overhaul of the levels will be needed once the conversion is done.
Also, I tried to stick to the levels that were there previously so since their
semantics changes too, now, that also introduces some small differences.
> * Please create ATA_MSG_DEBUG category and put
> important-but-not-too-frequent debug messages into it.
Can you please define those "important-but-not-too-frequent" more precisely and
support it with an example in the code?
> e.g. The current
> patch puts all debug messages during probe into CMD. Turning on CMD
> will generate a *lot* of messages and qc issues messages are sometimes
> very uninteresting. OTOH, probing messages are generally low-volume but
> more interesting. So, it should be possible to slect them separately.
> Just put not-too-frequent messages into DEBUG.
agreed
> * To me, DRV/INFO distinction doesn't seem to be clear.
INFO was revalidation messages, EH progress and DRV are standard driver
messages.
Regards,
Boris.
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
