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
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?
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
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!
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