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