Linux：如何将块设备映射到 USB 设备？
如果我插入 USB 记忆棒，我会在 /sys/bus/usb/devices 中看到一个新文件夹...因此是一个新的 USB 设备。
我还在 /sys/block 中看到一个新文件夹...因此是一个新的块设备。
我的问题是：如何在这两个设备之间获得防水映射？方法： 如果我在 /sys/bus/usb/devices 中获得一个新设备，我如何以编程方式（通过检查 /sys/...）找出哪个块设备映射/与此 USB 设备相关，反之亦然？ ！
if I plugin a USB memory stick, I see a new folder in /sys/bus/usb/devices ... thus a new USB-device.
Also I see a new folder in /sys/block ... thus a new block-device.
My question is: How can I get a waterproof mapping between those two devices? Means:
If I get a new device in /sys/bus/usb/devices, how can I programatically (f.i. by checking /sys/...) find out which block device is mapped/related to this usb-device and vice-versa?!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
/sys中的信息以多种方式组织（按驱动程序、按总线等），并且有许多符号链接可以从一个层次结构转到另一个层次结构。恰当的例子（内核 2.6.26 上看到的示例）：从
/sys/block/sdc中的块设备开始，符号链接/sys/block/sdc/device> 指向每个设备类型层次结构内部。您可以看到它是一个 USB 设备，因为链接的目标类似于 相反，USB 设备列在
/sys/bus/usb/devices中，我们可以看到8- 2:1.0是一个类似磁盘的设备，因为/sys/bus/usb/devices/8-2:1.0/driver链接到usb-storage。要找出关联的块设备是什么，我们似乎需要进入目录/sys/bus/usb/devices/8-2:1.0/host9/target9:0:0/9:0： 0:0，其中包含一个符号链接block:sdc，其目标是/sys/block/sdc。添加：警告：
/sys的确切结构因内核版本而异。例如，对于内核 2.6.32，/sys/block/sdc/device直接指向/dev/bus/scsi，无需通过 USB 跃点。另一种方法是调用 udevadm info 命令。
udevadm info -p /sys/block/sdc --query=...根据设备的/sys条目提供设备信息，而udevadm info -n sdc --query=...提供有关设备/dev/sdc的信息。这些信息包括总线信息，例如
udevadm info -p /sys/block/sdc --query=env显示udev 文档可能包含您感兴趣的更多信息。
最后要注意的是：有各种复杂的情况可能会使您所做的任何事情变得不那么防水。您的程序将如何处理单个 USB 设备（该设备是分配了多个块设备的磁盘阵列）？相反，您的程序将如何处理由多个设备（可能其中一些是 USB，一些不是）组装而成的 RAID 阵列？您是否关心其他可移动介质类型，例如 Firewire 和 e-SATA？您将无法预测所有极端情况，因此请确保优雅地失败。
The information in
/sysis organized in multiple ways (by driver, by bus, etc.), and there are many symbolic links to go from one hierarchy to another.Case in point (example seen on kernel 2.6.26): starting from the block device in
/sys/block/sdc, the symbolic link/sys/block/sdc/devicepoints inside the per-device-type hierarchy. You can see that it's an USB device because the target of the link is something likeConversely, USB devices are listed in
/sys/bus/usb/devices, and we can see that8-2:1.0is a disk-like device because/sys/bus/usb/devices/8-2:1.0/driverlinks tousb-storage. To find out what the associated block device is, it seems we need to go down to the directory/sys/bus/usb/devices/8-2:1.0/host9/target9:0:0/9:0:0:0which contains a symbolic linkblock:sdcwhose target is/sys/block/sdc.ADDED: Caution: the exact structure of
/syschanges from kernel version to kernel version. For example, with kernel 2.6.32,/sys/block/sdc/devicepoints directly into the/dev/bus/scsiwithout going through the USB hop.A different approach is to call the
udevadm infocommand.udevadm info -p /sys/block/sdc --query=…gives information on a device based on its/sysentry, whileudevadm info -n sdc --query=…gives information on the device/dev/sdc.The information includes bus information, for example
udevadm info -p /sys/block/sdc --query=envshowsThe udev documentation may have more information of interest to you.
A final word of caution: there are all kinds of complex cases that may make whatever you do not so waterproof. How will your program deal with a single USB device that is an array of disks that are assigned multiple block devices? Conversely, how will your program deal with a RAID array assembled from multiple devices (perhaps some of them USB and some of them not)? Do you care about other removable media types such as Firewire and e-SATA? etc. You won't be able to predict all corner cases, so make sure to fail gracefully.
据我发现，可以通过“libudev”库访问 udev 信息。网上还有一个很好的示例： http://www.signal11.us/oss/udev /
我能够修改它以读出所有“/dev/sd*”设备并获取它们的供应商 ID、产品 ID 以及序列号。我认为这个解决方案足够独立于内核/linux 发行版。但这一点我还得验证一下。
As far as I found out, it's possible to access udev information via "libudev" library. There's also a good sample on the net available: http://www.signal11.us/oss/udev/
I was able to modify it to read out all "/dev/sd*" devices and get their Vendor-ID, Product-ID as well as Serial number. I think this solution is kernel/linux distribution independant enough. But I still have to verify this.