From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Date: Tue, 16 Jun 2015 15:41:52 +0100 Message-ID: <558035B0.3070308@eu.citrix.com> References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <21887.64856.265751.921367@mariner.uk.xensource.com> <558000E5.9000803@suse.com> <21888.1058.681450.470806@mariner.uk.xensource.com> <5580079D.6070007@suse.com> <21888.4161.841504.686364@mariner.uk.xensource.com> <21888.9902.709503.386019@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21888.9902.709503.386019@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: =?windows-1252?Q?J=FCrgen_Gro=DF?= , Wei Liu , Ian Campbell , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On 06/16/2015 02:37 PM, Ian Jackson wrote: > George Dunlap writes ("Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API"): >> Remember that the path you gave in your previous e-mail isn't the path >> for the *usb device*, it's the path for the *block device*. It >> contains a PCI address, but it looks like it also contains part of the >> USB topology. Are you sure that's actually a stable interface, or >> does it just happen that on your hardware the discovery always happens >> in the same order? > > The block device is (in path terms) underneath the usb device, > obviously. Not all of that path is relevant to identifying the > USB device. > >> On my system /sys/bus/usb/devices/2-3.3 is a link to >> /sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3/2-3.3/. This contains >> the pci bus address, but it also contains the bus number, which we've >> just said may be unstable across reboots. > > You mean the 2 in `usb2' ? I think that bus number is the bus number > within the controller, not globally. On the contrary: $ ls -l usb* lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb1 -> ../../../devices/pci0000:00/0000:00:1a.7/usb1/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb2 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb3 -> ../../../devices/pci0000:00/0000:00:1a.0/usb3/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb4 -> ../../../devices/pci0000:00/0000:00:1a.1/usb4/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb5 -> ../../../devices/pci0000:00/0000:00:1a.2/usb5/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb6 -> ../../../devices/pci0000:00/0000:00:1d.0/usb6/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb7 -> ../../../devices/pci0000:00/0000:00:1d.1/usb7/ lrwxrwxrwx 1 root root 0 Jun 15 10:14 usb8 -> ../../../devices/pci0000:00/0000:00:1d.2/usb8/ $ ls /sys//devices/pci0000:00/0000:00:1d.7/ | grep usb usb2/ In other words, the global bus enumeration leaks its way into the device path; which means at very least the sysfs device path is potentially unstable across reboots even if you include the pci controller it's on. >> I suppose it might be possible to specify -- the pci >> address of the root bus, and the topology from there. In theory I >> guess that should be stable? > > Yes. The whole point of paths like this is that they are stable if > the physical topology doesn't change. So on my netbook > > /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1 > > always refers to the 1st MBR partition on logical device 0 on the USB > storage device plugged into the USB port physically on the front left > of the computer. That would be great if it were true, but I'm not convinced that the above path doesn't include a globally-enumerated bus number, which might change across reboots if it's enumerated in a different order. It may be that the format above is *not* based on the sysfs path of the device; that the '0' immediately after the USB means "the first (and perhaps only) controller at this PCI address". In which case, yes, having a string like this might be a unique identifier for a particular port that would be stable across reboots. That needs some investigation. >> In any case, at the moment you're essentially inventing from whole >> cloth a new way of specifying USB devices that (as far as I know) >> isn't supported by any other program that uses USB. > > If you can't specify the device by hardware path, you can't specify it > deterministically. > > And as you can see it _is_ supported by other programs that use USB. > "mount" can use it! Mount doesn't know anything about USB devices; all it knows are block devices. You might as well say that 'ls' knows about USB devices because it can read files on a filesystem that resides on a USB stick. I'm talking about programs that explicitly manipulate USB devices -- in particular, those that may pass them through to a guest or seize them, like libvirt, qemu, virtualbox, &c. I'm not opposed to doing something new if it really is better. But when you find that a dozen other projects before you have done things one way, you should at least take care before you decide to do something radically different, to make sure that it's because you actually have something better, and not because you've just missed something. > I think the hardware path to the controller, at least, should be > treated as an opaque OS-specific string. It might have a different > format on BSD. If we can make an actual path that's stable across reboots, that would certainly be a good thing. But if it's not stable across reboots, it has no advantage over the bus-port[.port.port] interface. -George