Re: work-around for video4linux sysfs

[Kay Sievers <kay.sievers@vrfy.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