Pete Zaitcev wrote:
From that angle, the tracing has to be in fact placed into HC drivers,
not into USB core (with attendant increase in overhead, I grant).
Placing it into usbfs borders on useless. The USB core might be
a good compromise if HC drivers are considered sufficiently solid.
That's true for 2.4 kernels ... but the 2.6 kernel has two obvious
places to put the hooks USBMon needs:
- hcd_submit_urb()
- usb_hcd_giveback_urb()
And the two spots are even marked with nice comments suggesting that
calls to a hcd_monitor_hook() be made there. That wouldn't catch the
"old style" HCDs, but we can't care about them much longer anyway.
So far as I can tell there are only a handful of basic design
questions:
* What urbs to monitor? Examples: all; only ones that have
a special transfer flag set; only ones on devices that have
a special tracing flag set.
* What to report about those urbs? Presumably device and endpoint,
plus status (on return) and maybe the data that's sent.
* How to report URBs? There could easily be multiple answers,
if the monitor hook is pluggable (or even chainable). The
most trivial one would use dev_dbg(). Fancier ones would
use reporting channels along the lines of what tcpdump uses.
This would be a good project for someone who wanted to give Linux
something along the lines of "usb snoopy" or "bushound". Don't
the "ethereal" folk want to plug in non-network tracing too?
- Dave
-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
