[patch 0/4] make pr_debug() dynamic

[patch 0/4] make pr_debug() dynamic

[Jason Baron]

hi,

make the pr_debug() function dependent upon the new immediate infrastruture.
Thus, b/c of the low runtime impact, we can dynamically enable/disable
pr_debug withoug recompiling. Patch allows 'pr_debug=0/1' on the command
line or via /proc/sys/debug/pr_debug.

thanks,

-Jason

Re: [patch 0/4] make pr_debug() dynamic

[Joe Perches]

On Thu, 2008-02-07 at 16:03 -0500, Jason Baron wrote:
> make the pr_debug() function dependent upon the new immediate infrastruture.

What's wrong with klogd -c 8 or equivalent?

Re: [patch 0/4] make pr_debug() dynamic

[Jason Baron]

On Thu, Feb 07, 2008 at 02:42:14PM -0800, Joe Perches wrote:
> On Thu, 2008-02-07 at 16:03 -0500, Jason Baron wrote:
> > make the pr_debug() function dependent upon the new immediate infrastruture.
> 
> What's wrong with klogd -c 8 or equivalent?
> 
> 

Setting the loglevel higher, will not make pr_debug() calls visible. The only
way to make them visible right now, is by re-compiling the kernel.

-Jason

Re: [patch 0/4] make pr_debug() dynamic

[Jan Engelhardt]

On Feb 8 2008 10:52, Jason Baron wrote:
>On Thu, Feb 07, 2008 at 02:42:14PM -0800, Joe Perches wrote:
>> On Thu, 2008-02-07 at 16:03 -0500, Jason Baron wrote:
>> > make the pr_debug() function dependent upon the new immediate infrastruture.
>> 
>> What's wrong with klogd -c 8 or equivalent?
>
>Setting the loglevel higher, will not make pr_debug() calls visible. The only
>way to make them visible right now, is by re-compiling the kernel.

pr_debug() was IMHO meant to be a compile-time optimization
to throw out debug messages most people do not want.

If you want to switch on/off debugging messages, use
printk(KERN_DEBUG) [with klogd -c something] and not pr_debug!

Re: [patch 0/4] make pr_debug() dynamic

[Jason Baron]

On Sat, Feb 09, 2008 at 11:21:58PM +0100, Jan Engelhardt wrote:
> >> 
> >> What's wrong with klogd -c 8 or equivalent?
> >
> >Setting the loglevel higher, will not make pr_debug() calls visible. The only
> >way to make them visible right now, is by re-compiling the kernel.
> 
> pr_debug() was IMHO meant to be a compile-time optimization
> to throw out debug messages most people do not want.
> 
> If you want to switch on/off debugging messages, use
> printk(KERN_DEBUG) [with klogd -c something] and not pr_debug!

true, we could turn pr_debug() calls into printk(KERN_DEBUG) calls, but there
is an overhead to all these extra printk functions calls. The way I have
implemented pr_debug(), there is no function call at all, in the off case.
To me pr_debug() is currently a compile option, b/c there is often a lot of
overhead to having it on. Being able to turn pr_debug() calls off/on in a
production environment, to get debugging data seems very valuable.

thanks,

-Jason