Re: work-around for video4linux sysfs

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, 2007-08-06 at 17:39 -0700, Kees Cook wrote:
> On Fri, Aug 03, 2007 at 12:30:12AM +0200, Kay Sievers wrote:
> > > 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
> 
> Unfortunately, you can have multiple of the same type for the same PCI
> instance,

You have multiple drivers bound to the same device? Or multiple
instances of the same type created by the same driver.

> which I worked around in the original patch.

If they are from the same driver, you just overwrite the earlier created
links with your patch, right?

> This is related
> to how some v4l drivers deal with multiple output modes from the same
> card[1] (e.g. MPEG2 encoder output, YUV output, audio only output, etc,
> are associated with an offset minor number).  It's really ugly.  :(

Then the kernel should provide a unique "function" string, which can be
used to name the device.

> What I did was limit the by-path links to only the first 10 video
> devices:

Yeah, that's ugly.

> +# This is limited to the first 10 video devices to avoid per-driver 
> +# device duplication (like ivtv), since we have no way to distinguish
> +# interfaces via sysfs in a driver-agnostic way yet.  If OPTIONS allowed
> +# replacement, we could set link_priority to -%m to give preference to the
> +# first v4l interface per physical device.
> +ENV{ID_PATH}="?*", KERNEL="video[0-9]", SYMLINK+="v4l/by-path/$env{ID_PATH}"
> 
> If %m was expanded in OPTIONS, then preference in links could be given
> to the first interface a driver assigned for a given card.  Beyond that,
> I could only think to avoid ivtv's minor id assignment ugliness by just
> not support having >10 video cards in the same system, which didn't seem
> like too bad of a compromise.

We need to solve the problem proper, that all sounds like a quick and
dirty hack which, in its current form, can not be provided by udev.
We are not going to create any links based on the kernel driver name,
nor will we limit the number of links per device, or overwrite links
with magic priorities.

If we can have multiple, say "video3", "video4", "video5" at the same
device, the kernel should export a unique string in sysfs/ or uevent
env, for every of these devices based on the function, like: "yuv:,
"enc", "audio", ... which we can append to the name:
  pci-0000:01:06.0-video-yuv -> ../../video0
  pci-0000:01:07.0-video-enc -> ../../video1

Otherwise how is userspace expected to find the other nodes? It sounds
pretty weird to limit the persistent nodes to the "first" device.

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