From: Greg Banks Subject: Re: [RFC][PATCH 0/5] NFS: trace points added to mounting path Date: Thu, 22 Jan 2009 09:36:53 +1100 Message-ID: <4977A385.8000406@melbourne.sgi.com> References: <4970B451.4080201@RedHat.com> <5B2817A2-B0FF-4FB5-9244-9E13C55EF6B2@oracle.com> <497757D1.7090908@RedHat.com> <49777988.6010401@RedHat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Linux NFS Mailing list , Linux NFSv4 mailing list , SystemTAP To: Chuck Lever Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfsv4-bounces@linux-nfs.org Errors-To: nfsv4-bounces@linux-nfs.org List-ID: Chuck Lever wrote: > > > I think we need to visit this issue on a case-by-case basis. > Sometimes dprintk is appropriate. Sometimes printk(KERN_ERR). > Sometimes a performance metric. Well said. > Trond has always maintained that dprintk() is best for developers, but > probably inappropriate for field debugging, It's not a perfect tool but it beats nothing at all. > and I think that may also > apply to trace points. It depends on whether distros can be convinced to enable it by default, and install by default any necessary userspace infrastructure. The most important thing for field debugging is Just Knowing that you have all the bits necessary to perform useful debugging without having to find some RPM that matches the kernel that the machine is actually running now, and not the one that was present when the machine was installed. -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI.