On Sun January 23 2011 08:13:50 Bob Copeland wrote: > This adds a few tracepoints to ath5k driver transmit and > receive callbacks in order to record packet traffic. > We record the entire packet in the trace buffer so that > the data can be extracted with trace-cmd and external > plugins. > > This approach removes an out-of-line function call > from the tx and rx paths when the debugging is compiled > in but disabled, while improving the ability to process > the logged data. A new Kconfig option can disable the > tracepoints completely. > > The corresponding debug dump functions are removed. > > Signed-off-by: Bob Copeland <m...@bobcopeland.com> > --- > > (Actually this patch doesn't remove the debug_dump_skb() functions but > I'll probably do that before sending it on...) > > I've been carrying this locally for a while and rebasing it, what are > thoughts on sending this upstream now? > > Last time not everyone was sold on changing all debug to tracepoints, > so how about just these two? I doubt anyone is really using debug > rx/tx since it produces so much log spam and there's no easy way to > post-process the data.
I have been using it last time a few years ago, by manually "parsing" the packets out of the hexdump. Yes, it was tedious... > I find this pretty useful for correlating > the mac80211 tracepoints with ath5k -- for example, it's easy to see > where the PS code decides to send a nullfunc frame, and trace that > through ath5k's ->tx() because the timestamps all match up. After giving it a try, I agree that this is the better way. Please go ahead. > b/drivers/net/wireless/ath/ath5k/ath5k_trace.h new file mode 100644 Maybe trace.h would be enough. We are in ath5k/ already. bruno _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
