On Tue, 7 Jan 2020, Tomasz Moń wrote: > On Tue, Jan 7, 2020 at 6:41 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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
