On Thu, 2009-01-22 at 09:36 +1100, Greg Banks wrote: > 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. Which is precisely why dprintk() is such a bad choice as a basis for a set of trace points: every new patch and bugfix that the distro applies will result in a reshuffling of the trace points as code is cleaned up and moved around or removed entirely. Cheers Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
