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

[Phillip Susi <psusi@cfl.rr.com>]

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.