Re: [PATCH 2/13] ATA ACPI: debugging infrastructure

[Phillip Susi]

Andrew Morton wrote:
> Except
>
> - There's (presently) no way of making all the messages go away for a
>   non-debug build.

I agree, there should be a config option to build the kernel with the 
debug support entirely shut off, though it's a good idea to leave it on 
if you aren't really cramped for space.

> - The code is structured as
>
> 	if (ata_msg_foo(p))
> 		printk("something");
>
>   So if we later do
>
> 	#define ata_msg_foo(p)	0
>
>   We'll still get copies of "something" in the kernel image (may be fixed
>   in later gcc, dunno).
>
> - The new debug stuff isn't documented.  One has funble around in the
>   source to work out how to even turn it on.  Can it be altered at runtime?
>   Dunno - the changelogs are risible.  What effect do the various flags
>   have?
>
>   Having spent (and re-spent) time grovelling through the ALSA source
>   working out how to enable their debug stuff during a maintainer snooze
>   I'd prefer we didn't have to do that with libata as well.

Would you prefer there not be any debug messages at all, rather than 
ones you have to figure out how to turn on and interpret?  Documentation 
is always a good thing, but if you are at least somewhat familiar with 
the code, turning on the debug messages should be easy and rather helpful.

BTW, didn't I see something recently in the kernel about a debug fs? 
Sounded like that was intended for this sort of thing to provide a 
standard interface to configuring fine grained debug message filtering.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/