From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 02 Aug 2007 22:30:12 +0000 Subject: Re: work-around for video4linux sysfs Message-Id: <1186093812.3443.21.camel@lov.localdomain> List-Id: References: <20070731195136.GW9881@outflux.net> In-Reply-To: <20070731195136.GW9881@outflux.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Thu, 2007-08-02 at 07:05 -0700, Kees Cook wrote: > On Thu, Aug 02, 2007 at 11:24:08AM +0200, Kay Sievers wrote: > > We will not create any persistent links which contain simple > > enumeration or driver names. That just doesn't make sense. Driver > > names are kernel implementation details that are free to change any > > time, you can match on them with rules, but not put them into > > persistent link names. > > This doesn't seem consistent with things I saw in /dev/disk/by-path, > but I'm totally open to suggestions for /dev/v4l. e.g.: > > pci-0000:00:0e.0-scsi-0:0:0:0-part1 > ^driver > ^simple enumeration It's the subsystem not the driver. And it's not an enumeration based on discovery order, it's the PCI slot number which doesn't change, also SCSI uses stable interface and port numbers here. Here is a USB hard drive: pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0-part1 -> ../../sdb1 or a USB mouse: pci-0000:00:1d.2-usb-0:1:1.0-mouse There are only the subsystem names and the non-changing numbers of the subsystems. For USB it's the port number on the hub, which is the only thing we can distinguish identical devices sometimes. > Things like the hda/sda swap for SATA changed the driver name here, > so I don't think it's unreasonable to use a driver name as part of > the symlink. Only if you use the kernel names, which you shouldn't. Ubuntu uses uuids, Red Hat labels, and SUSE uses the hardware serial numbers in fstab, so even when the driver changes, everything should continue to work. The kernel is always free to plug in a better driver without expecting anything to break. That doesn't work sometimes, but we should try hard no to make any dependencies on kernel implementation details. > The simple enumeration in this case is based on physical > characteristics of the device, which I can see as being different from > the per-driver v4l enumeration. > > Note, however, that my proposed code does not use the per-driver > enumeration because there was no way to access it reliably. The > proposed code produces a tree like so: > > /dev/v4l > `-- by-path > |-- pci-0000:01:06.0-cx8800 -> ../../video0 > `-- pci-0000:01:07.0-ivtv -> ../../video1 > > > Also the enumeration number appended to the end of the name creates > > more problem than is solves, because it again depends on discovery > > order of the device, which can also change at any time. > > AFAIK, the v4l per-driver enumeration has a fixed order (i.e. ivtv0, > ivtv1). (The general v4l device enumeration is not -- video0, video1). You can never rely on that, the kernel is also free to change that whenever necessary. > Again, I just want a unique identifier for the v4l devices, and was > offering a working code example. Without the driver-name-fetching, the > path-id output had this ugly trailing "-", which seemed to be calling > for more stuff to be put after it. (e.g. "pci-0000:01:06.0-") Yeah, that's because it doesn't handle the v4l subsystem today. > I have no problem changing it to be more in line with what you'd like > to see; I just want to solve the problem. :) Can you make some > suggestions on what a clean solution would look like? Can there be more than one device of the same type at the same pci instance? If not why not just have: pci-0000:01:06.0-video -> ../../video0 pci-0000:01:07.0-video -> ../../video1 For USB devices it could just look like: pci-0000:00:1d.2-usb-0:1:1.0-video -> ../../video0 pci-0000:00:1d.2-usb-0:1:1.0-radio -> ../../radio0 Thanks, Kay ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel