From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sander Eikelenboom Subject: Re: [PATCH V4 3/7] libxl: add pvusb API [and 1 more messages] Date: Tue, 16 Jun 2015 17:58:25 +0200 Message-ID: <738931034.20150616175825@eikelenboom.it> 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> <558035B0.3070308@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <558035B0.3070308@eu.citrix.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: George Dunlap Cc: =?windows-1252?Q?J=FCrgen_Gro=DF?= , Wei Liu , Ian Campbell , Ian Jackson , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org Tuesday, June 16, 2015, 4:41:52 PM, you wrote: > 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 Would a symlink to a sysfs or device node entry also be allowed ? That way you can leverage the power of tools like udev or other device managers and script the linkage based on a multitude of device properties (f.e. serial numbers, manufacturer id, device id, etc.). Which can make it persistent across reboots or do other funky stuff with it, according to ones needs. -- Sander