From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Wed, 01 Aug 2007 22:39:24 +0000 Subject: Re: work-around for video4linux sysfs Message-Id: <20070801223924.GA31236@kroah.com> 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 Wed, Aug 01, 2007 at 03:22:56PM -0700, Kees Cook wrote: > On Wed, Aug 01, 2007 at 02:58:35PM -0700, Greg KH wrote: > > On Wed, Aug 01, 2007 at 02:31:30PM -0700, Kees Cook wrote: > > > Is the idea of /dev/v4l/by-path/... sane? Once v4l sysfs was fixed, > > > it seems that to support this symlink, the path_id tool would still need > > > at least the second patch hunk. Is this correct? > > > > Probably, and yes, the v4l by-path stuff is a good idea, I'm not trying > > to keep that from happening. But are there ids on these devices you can > > use too, to get a "by-id" path as well? Do the USB or PCI devices have > > a serial number associated with them? > > If there are serial numbers, the v4l sub-drivers aren't fetching them, > or I'm too dense to find them. USB serial numbers are up in the USB device, which you should be able to get by just walking up the device chain in sysfs. PCI devices on their own don't have a standard for serial numbers :( > This is basically why I opted for the by-path symlinks, since nothing > else looked like a reasonable unique string. I had originally hoped > to build one using something like: > > $driver_name-$device_type_name-$driver_init_order > > For example, if I had 2 ivtv devices, and one bttv device, I'd expect to > see something like: > > ivtv-pvr250-0 > ivtv-pvr500-1 > bttv-thingy-0 > > But the v4l drivers don't have a common string for the "device_type_name" > in my example. (They have a long description string that is usually > truncated, but whose layout isn't common between drivers.) While ivtv > internally knows about ivtv0 and ivtv1, there doesn't seem to be a way > to query a v4l driver about which sub-instance it is. This might be > another nice thing to plumb into sysfs, but I imagine it would be needed > for each v4l driver. Ick, that sounds messy :( > In the 3 example devices above, ivtv0 always inits before ivtv1 in the > same order, but bttv may come before ivtv, swapping the video0, video1, > video2 devices all over the place. > > > > By my estimation, the v4l sysfs is missing a "driver" linkage? I'm not > > > entirely sure where to start looking. > > > > What does the v4l device sysfs directory tree look like? Is the > > "driver" link the only thing you are missing to do this in an easier > > manner in your script? > > I think if that was in there, it would at least solve the current gross > need to cd into the directory to pull a PWD. :) There may still be a > need to append the driver name to the path-id output, but I suspect that > would be simple to do in the already-needed second hunk of the patch. Can you show me the sysfs representation for the v4l devices you have? thanks, greg k-h ------------------------------------------------------------------------- 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