Re: [PATCH v2 13/51] IB/qib: Add qib_driver.c
Roland Dreier wrote: > > Where can I find information on trace events? Something in > Documentation/*? > > Yep, Documentation/trace/events.txt. LWN just did a really good writeup on using the TRACE_EVENT macro: http://lwn.net/Articles/379903/ Part 2 is still behind the paywall. -John Gregor -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/51] IB/qib: Add qib_driver.c
> Where can I find information on trace events? Something in Documentation/*? Yep, Documentation/trace/events.txt. Also look at eg include/trace/events/ext4.h and how the trace_ext4_{xxx} functions are used in fs/ext4/*. It's much better than anything you're going to hack up for a single driver to use. - R. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/51] IB/qib: Add qib_driver.c
Roland Dreier wrote: > +unsigned qib_debug; > +module_param_named(debug, qib_debug, uint, S_IWUSR | S_IRUGO); > +MODULE_PARM_DESC(debug, "mask for debug prints"); Did you look at using trace events for this stuff? That gives you extremely low overhead when tracing is turned off (dynamic patching to NOP out the tracing when it's disabled) and also very fine-grained (per trace site) control over what gets printed; plus you get dumping of the trace buffer on crash, etc. - R. Where can I find information on trace events? Something in Documentation/*? Thanks, Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/51] IB/qib: Add qib_driver.c
> +DEFINE_MUTEX(qib_mutex);/* general driver use */ Rather than having this ill-defined mutex that I think is going to make it hard to understand the locking and get the lock ordering right, would it be better to have well-defined locking rules? AFAICT this mutex is used in only two places, qib_diag.c and qib_file_op.c. Are those two uses protecting the same thing? Or could we have two static mutexes, one in each file, that protects what each file needs protected? -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 13/51] IB/qib: Add qib_driver.c
> +unsigned qib_debug; > +module_param_named(debug, qib_debug, uint, S_IWUSR | S_IRUGO); > +MODULE_PARM_DESC(debug, "mask for debug prints"); Did you look at using trace events for this stuff? That gives you extremely low overhead when tracing is turned off (dynamic patching to NOP out the tracing when it's disabled) and also very fine-grained (per trace site) control over what gets printed; plus you get dumping of the trace buffer on crash, etc. - R. -- Roland Dreier || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html