Thanks, Scott. These are basically the same potential solutions I discovered when first analyzing this bug. I'd like to add my perspective to this discussion, since I'll probably be implementing VMware's support for /dev/bus/usb.
The three separate issues in /dev/bus/usb migration deserve separate consideration: 1. Opening and interacting with individual USB devices This should be as simple as using /dev/bus/usb/<bus>/<device> instead of /proc/bus/usb. Permissions issues aren't a huge concern at the moment, since VMware uses its suid-root privileges to open devices- but that's a separate discussion. Besides compatibility with Ubuntu/SuSE/etc, this would be a step towards being a better citizen with regard to permissions on desktop machines. 2. Enumerating attached devices We used /proc/bus/usb/devices for this previously. The new solution is sysfs, as you mentioned. Sysfs has all the information our products need, but it has some disadvantages. For any program which needs multiple pieces of information about multiple devices, it's complicated and racy. With /proc/bus/usb/devices, I could atomically read all information about all devices. With sysfs, devices could appear/disappear/change at any time. This problem is tractable, but adds complexity. 3. Notifications of connected/removed devices With /proc/bus/usb/devices, one could just poll() to get notified when something changed. Without that file, there are several other options to consider. We could have a helper program executed via udev, as you mentioned. That would work fine for our purposes, but I'd rather avoid the headache of installing and maintaining udev rules for all Linux distros VMware supports. Then there's HAL. This is often touted as the "correct" solution- and I'm sure it is for your average gnome or kde app. Our USB code, however, needs to run in environments where I doubt we can rely on HAL to exist. VMware already does use HAL, but only from the GUI- not from the actual virtual machine process. As Petr mentioned, we've already had problems with HAL/DBus compatibility. The solution I'm leaning toward right now is to listen directly from the netlink socket. It does require root privileges, but we can use our suid-root bit. The only real downsides I see are: - Theoretically, the format of the messages on the netlink socket may change. - The uevent netlink socket is new in Linux 2.6.10. There are distros in the wild (SLES9 SP3) with older kernels which don't mount /proc/bus/usb. -- USB devices are not shown in /procu/bus/usb/ causing VMWare to fail to see them https://launchpad.net/bugs/35004 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
