Em Wed, Jan 21, 2009 at 11:39:56AM -0500, Steve Dickson escreveu:
> K.Prasad wrote:
> > 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?
> 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...
I suggest you provide an ftrace plugin, just like I'm doing with
blktrace, see:
http://lkml.org/lkml/2009/1/20/190
- Arnaldo
Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 21, 2009 at 11:39:56AM -0500, Steve Dickson escreveu:
>> 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...
>
> I suggest you provide an ftrace plugin, just like I'm doing with
> blktrace, see:
>
> http://lkml.org/lkml/2009/1/20/190
I agree its something I need to look into...
steved.