Hi - On Mon, Jan 19, 2009 at 10:12:55AM +1100, Greg Banks wrote: > [...] > > It would make more sense to me to turn dprintk's into trace_marks, > Umm, ok. Sorry to be so ignorant but where would I find the doc that > tells me about adding trace marks ? Documentation/markers.txt > The control interface seems a little primitive. It seems like you > can only activate and deactivate single printks ? Or single classes (identical names) per activate/deactivate call. > I don't see a way to e.g. activate every trace make in a particular > function, or in a particular .c file. I thought both of these were > useful things to do, so I implemented them. Below is an extract > from the doc that accompanies the sgi-dprintk module. [...] Very clever! I am not an insider enough to carry much weight in this regard, but it would make most sense to me if the sgi-dprintk widget were adapted so that: - it used trace_mark() as the low-level hook mechanism at the call sites - it extended the trace_mark structures to track __FILE__/__LINE__/__FUNCTION__ values - it extended the marker activation API to be able to specify queries based upon those __FILE__/etc. fields - as an extension to the proposed marker->ftrace patch, extend the option parser the same way as your /proc/dprintk does The benefits might not be huge, but: - it would reuse existing functionality (markers for the hooks, other ftrace widgets for extra info to gather at each event - like the stack traces) - it could generalize the handling of these dprintks, by not just being tied to message printing, but becoming of possible use for statistics/health monitoring - FChE -- 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
