[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <466C5112.4090004@hawkeye.stone.uk.eu.org>
Date: Sun, 10 Jun 2007 20:29:22 +0100
From: Jack Stone <jack@...keye.stone.uk.eu.org>
To: Randy Dunlap <randy.dunlap@...cle.com>
CC: linux-kernel@...r.kernel.org, hpa@...or.com,
Ian Kent <raven@...maw.net>
Subject: Re: [PATCH 0/7] Cleanup code to replace DPRINTK with pr_debug
Randy Dunlap wrote:
> Hi,
>
> Doesn't this move printk-debug control from local source files
> (i.e., targeted, specific ones) to a more global control (DEBUG)?
>
> If so, I don't see that as a generally good thing.
>
> If not, please correct me and tell me how this is useful to just
> one instance of using pr_debug() in say, ncpfs, without pr_debug()
> being enabled throughout the entire kernel tree.
>
> Thanks.
I can certainly see that point but using pr_debug means that all the
debug print statements are centralised so that changes to the format
could be more uniform. For example, it would be very easy to change the
macro to print the function name it was called from followed by the message.
The only DPRINTK's with specific DEBUGs were alternative.c, which had an
extra if, and ncpfs which had an extra #ifdef DEBUG_NCP. The alternative
solution would be to change the #defines to use pr_debug rather than
printk directly:
#define DPRINTK(format, args...) \
pr_debug(format, ##args);
The advantage would be maitaining subsystem specific debug control with
centralised format control.
Jack
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists