linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: work-around for video4linux sysfs
Date: Wed, 01 Aug 2007 22:39:24 +0000	[thread overview]
Message-ID: <20070801223924.GA31236@kroah.com> (raw)
In-Reply-To: <20070731195136.GW9881@outflux.net>

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

  parent reply	other threads:[~2007-08-01 22:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-31 19:51 work-around for video4linux sysfs Kees Cook
2007-08-01 20:52 ` Greg KH
2007-08-01 21:31 ` Kees Cook
2007-08-01 21:58 ` Greg KH
2007-08-01 22:22 ` Kees Cook
2007-08-01 22:39 ` Greg KH [this message]
2007-08-01 23:14 ` Kees Cook
2007-08-01 23:28 ` Greg KH
2007-08-01 23:48 ` Kees Cook
2007-08-02  9:24 ` Kay Sievers
2007-08-02 14:05 ` Kees Cook
2007-08-02 22:30 ` Kay Sievers
2007-08-02 22:39 ` Linas Vepstas
2007-08-02 23:02 ` Kay Sievers
2007-08-07  0:39 ` Kees Cook
2007-08-07  9:24 ` Kay Sievers
2007-08-07 19:36 ` Kees Cook
2007-08-07 22:58 ` Kay Sievers
2007-08-07 23:18 ` Kees Cook
2007-08-08 10:48 ` Kay Sievers
2007-08-09 19:38 ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070801223924.GA31236@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).