Aquire mount point of storage devices

[tuna-f1sh]

Would be a nice feature (re: kevinmehall/nusb#119). Not sure yet how to obtain details cross-platform - or if easily possible.

Rough idea:

• Add a mount_point() method to Device that returns Option<Path>. If device is MSD, attempt to find mount point.
• Add DeviceBlock::MountPoint for display.

On Linux, could I think cross reference from /dev/disk/by-path?

[kevinmehall]

device.mount_point() would be an oversimplification, because there are several layers in between USB devices and mount points. Each layer can have multiple instances, so it's actually a tree, and there's interesting metadata at each layer.

• USB device
• USB interfaces, some of which may be Mass Storage Class
• Logical Units
• Partitions
• Filesystems
• Mount points

[tuna-f1sh]

Thanks for pointers. Will have a look when done with #58 . Might be out of scope for just USB device listing too.

[tuna-f1sh]

You're right there are many layers to this. Probably things you're aware of but capturing for my own exploration.

I think the block device could be captured for each LUN of a mass storage device using '/dev/disk/by-id'. The id is usb-$INQUIRYSTRING_$IPRODUCT_$ISERIAL-0:$LUN_NUMBER. Playing with https://github.com/surban/usb-gadget/blob/master/tests/msd.rs for example, assigning a string to the lun2 "Lun 2" (and removing cdrom flag):

❯ ls /dev/disk/by-id
usb-Linux_File-Stor_Gadget_serial_number-0:0  usb-Lun_2_product_serial_number-0:1

These symblic links point to the block device. The slightly confusing thing is the $IPRODUCT is trimed from the LUN without an inquiry string, taking just the gadget default.

❯ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda      8:0    1    1M  0 disk
sdb      8:16   1    1M  0 disk

I guess the question then is where to put each block device. One Mass Storage Class interface could have more than one LUN and each device could have many Mass Storage Class interfaces. And then each LUN could have many partitions for the actual mount point!

Might require a specific part of the tree for just Mass Storage Class interfaces as you suggest.