Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path

[Greg Banks <gnb at melbourne dot sgi dot com>]

Steve Dickson wrote:
> Greg Banks wrote:
>   
>> 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?
>   

Yes, and it would have the same value.  When I get back from LCA next
week I want to look at how one would fit that control mechanism into
trace points.
>   
>> 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... 
>   
Indeed, but it would be a starting point.
>   
>> 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... 
>   
I would hope that there would be *more* tracepoints than dprintks.

-- 
Greg Banks, P.Engineer, SGI Australian Software Group.
the brightly coloured sporks of revolution.
I don't speak for SGI.