Messages in this thread | | | Date | Tue, 28 Feb 2006 12:10:04 -0500 | From | Phillip Susi <> | Subject | Re: [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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |