On Mon, Jan 19, 2009 at 09:27:30AM -0500, Jeff Moyer wrote: > Greg Banks <gnb@xxxxxxxxxxxxxxxxx> 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 indeed. I've implemented a solution in a very similar problem space which is now upstream, see: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=346e15beb5343c2eb8216d820f2ed8f150822b08;hp=33376c1c043c05077b4ac79c33804266f6c45e49 One of the core fundamental differences that I see is that 'dprintk' checks a global variable per dprintk line. Whereas, 'dynamic printk' assigns each module a set of bits in a *single* global variable. The idea was that if you have thousands of these debug lines throughout the kernel, I wanted to have a small footprint. The per-dprintk granularity could be implemented on top of the per-module approach that i've taken. That is, each dprintk statement could activate the module that its associated with when its activated. Then, a further per-line variable could be checked. We should probably move this discussion to lkml, since this probably should involve a wider audience. Perhaps, you can re-post your patchset there? thanks, -Jason -- 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
