Re: Use of address 0 in usbmon

[Alan Stern <stern@rowland.harvard.edu>]

On Tue, 7 Jan 2020, Tomasz Moń wrote:

> On Tue, Jan 7, 2020 at 6:41 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > Before the patch you sent in yesterday, usbmon reported these requests
> > as directed to device number 1 (which is the number assigned to root
> > hubs since they are the first devices registered on their USB buses),
> > not 0.
> 
> Thank you for mentioning this.
> 
> > > Would it be possible to modify the usbmon format, so the
> > > is_root_hub(urb->dev) flag would be somehow available to the
> > > user-space tools?
> >
> > How about using address 255 in the usbmon output to represent root
> > hubs?  That wouldn't require any format change at all.
> 
> Yes, that's one possibility.
> 
> > By the way, there is one bad aspect to your patch.  Although the device
> > addresses output by usbmon will now correspond exactly to the physical
> > addresses on the bus, they will not correspond to the device numbers
> > used everywhere else in the kernel.  For example, someone monitoring
> > communcations with /dev/bus/usb/001/005 won't know what device address
> > to look for in the usbmon output -- it might not be 005.
> 
> Initially I have modified also the drivers/usb/core/devices.c to
> change the format_topo to use devaddr instead of devnum. Then I
> realised it could cause a snowball effect and decided to limit the
> change to usbmon only.
> 
> I think the solution to would be to extend usbmon format to include
> both devnum and devaddr. This unfortunately would require format
> change.

Maybe a better answer is to leave usbmon alone and instead add a new
devaddr attribute file to sysfs, containing the device's physical
address.  Then user programs could easily perform the conversion.

Alan Stern