[lkml]   [2006]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/13] ATA ACPI: debugging infrastructure
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-28 18:14    [W:0.085 / U:1.040 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site