This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path
Greg Banks wrote:
>
> These are two separate proposals between which we're trying to find some
> commonality.
I agree.. a common effort does make the most sense... imho...
>
> In my proposal, the dprintk()s remain designed primarily for humans
> (support staff or kernel developers) to read in conjunction with the
> correct source code, but control is made fine-grain to make the
> mechanism more controllable. This can be done regardless of whether
> trace points are involved and regardless of whether we attempt to
> support scripts.
I would think it the "fine-grain control mechanism" could also manage
trace points as well, true?
>
> Changing dprintk() to add a trace point is just a way to get some trace
> points with strictly minimum changes to callsites.
I'm not sure this would be a good idea since, as Trond or Chuck pointed out,
there is really not rhyme or reason on where the dprintks live today...
>
> Replacing dprintk()s with new trace points has more or less the same
> result but means more futzing with callsites.
Well not if the replacements are well thought out and designed, since
there does not have 1-to-1 replacement...
>
> The maintenance problem of correlating any kind of instrumentation point
> in kernel code with scripts living out in userspace exists regardless of
> how you choose to implement the instrumentation.
>
+1
steved.