On Mon, Jan 19, 2009 at 09:27:30AM -0500, Jeff Moyer wrote:
> Greg Banks <gnb-cP1dWloDopni96+mSzHFpQC/[email protected]> writes:
>
> > Steve Dickson wrote:
> >> So the ultimate goal would be to replace all the dprintks with trace points
> >> but still be able to enable them through the rpcdebug command
> > I have a patch which changes the definition of the dprintk() macro (but
> > *not* dprintk() callsites) to allow enabling and disabling individual
> > dprintk() statements through a /proc/ interface. Would you be
> > interested in that?
>
> That sounds like duplicated work. How does it differ from Jason Baron's
> dynamic printk patches (which I believe are now upstream)?
>
> Cheers,
> Jeff
Introducing/converting one of the accepted methods of static
instrumentation - like tracepoints would help more users (whether
in-kernel or otherwise) harness them.
Steve,
Would it help convert the systemtap script (nfs_mount.stp) in
Patch - 5 into a kernel module (perhaps in samples/ directory) to bring
an in-kernel user of these tracepoints?
Thanks,
K.Prasad
K.Prasad wrote:
> On Mon, Jan 19, 2009 at 09:27:30AM -0500, Jeff Moyer wrote:
>> Greg Banks <[email protected]> writes:
>>
>>> Steve Dickson wrote:
>>>> So the ultimate goal would be to replace all the dprintks with trace points
>>>> but still be able to enable them through the rpcdebug command
>>> I have a patch which changes the definition of the dprintk() macro (but
>>> *not* dprintk() callsites) to allow enabling and disabling individual
>>> dprintk() statements through a /proc/ interface. Would you be
>>> interested in that?
>> That sounds like duplicated work. How does it differ from Jason Baron's
>> dynamic printk patches (which I believe are now upstream)?
>>
>> Cheers,
>> Jeff
>
> Introducing/converting one of the accepted methods of static
> instrumentation - like tracepoints would help more users (whether
> in-kernel or otherwise) harness them.
>
> Steve,
> Would it help convert the systemtap script (nfs_mount.stp) in
> Patch - 5 into a kernel module (perhaps in samples/ directory) to bring
> an in-kernel user of these tracepoints?
Well nfs_mount.stp was just an example of how to pull the information
from the kernel.. I just wanted to complete the loop... but as
Christoph pointed out it probably shouldn't been included in the posting.
I'm not sure moving the nfs_mount.stp script into kernel
would make sense. One of the advantages of trace point and system
scripts (depending on what is passed up) it allows users to define
exactly what they need to see..
For example, a kernel guy might be interested in a particular bit in a flag
field which would be meaningless to an IT guy. On the other hand, the IT guy
would be interested in the error code. One trace point could supply all the
information but different systemtap scripts would be need to show the
desired information.
My point being, if we move things down into the kernel, I think we would
lose this type of flexibly...
steved.