work-around for video4linux sysfs

work-around for video4linux sysfs

[Kees Cook]

Hi,

I proposed the change below while Kay and Scott were at GUADEC, and
it seems the response was generally negative, but without any better
suggestions.  I'd like to bring this up again, as I think this solution,
while being a bit of hack, should at least be forward-compatible if/when
v4l sysfs stuff is sorted out better.

These patches create a /dev/v4l/by-path tree so that devices can
be explicitly identified (I could find no other common-across-v4l
uniquely identifying information).  Explicit symlinks are needed since
initialization order between v4l sub-drivers isn't always in the same.
Things like MythTV get very upset when /dev/video0 and /dev/video1 swap
places, for example...

First are changes to extras/path_id/path_id to handle missing driver
links, followed by changes to the debian rule set, as an example of how
the changes to path_id could be used.

Suggestions, thoughts?

Thanks,

-Kees


--- udev-113~/extras/path_id/path_id	2007-07-18 11:07:15.000000000 -0700
+++ udev-113/extras/path_id/path_id	2007-07-18 11:08:05.000000000 -0700
@@ -551,6 +551,17 @@ handle_device () {
 			d="$d-${rewind}st${mode}"
 		fi
 	fi
+	# v4l sysfs tree doesn't include driver details
+	if [ "$TYPE" = "video4linux" ] ; then
+		if [ -e "$full_sysfs_device_path/driver" ]; then
+			cd "$full_sysfs_device_path"/driver
+			driver="`pwd -P`"
+			cd "$OPWD"
+			if [ -n "$driver" ]; then
+				d="${d}${driver##*/}"
+			fi
+		fi
+	fi
 }
 
 case "$TYPE" in
@@ -566,6 +577,10 @@ case "$TYPE" in
 		handle_device
 		echo "ID_PATH=$d"
 		;;
+	video4linux)
+		handle_device
+		echo "ID_PATH=$d"
+		;;
 	*)
 		RESULT=1
 		;;


diff -u udev-113/debian/rules.d/60-symlinks.rules udev-113/debian/rules.d/60-symlinks.rules
--- udev-113/debian/rules.d/60-symlinks.rules
+++ udev-113/debian/rules.d/60-symlinks.rules
@@ -16,0 +17,14 @@
+
+# Create video4linux PCI path symlinks
+ACTION!="add", GOTO="video4linux_path_end"
+SUBSYSTEM!="video4linux", GOTO="video4linux_path_end"
+
+IMPORT{program}="path_id %p"
+# 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}"
+
+LABEL="video4linux_path_end"


-- 
Kees Cook

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Greg KH]

On Tue, Jul 31, 2007 at 12:51:37PM -0700, Kees Cook wrote:
> Hi,
> 
> I proposed the change below while Kay and Scott were at GUADEC, and
> it seems the response was generally negative, but without any better
> suggestions.  I'd like to bring this up again, as I think this solution,
> while being a bit of hack, should at least be forward-compatible if/when
> v4l sysfs stuff is sorted out better.

Why can't we just fix the kernel code to do the right thing?

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

Re: work-around for video4linux sysfs

[Kees Cook]

On Wed, Aug 01, 2007 at 01:52:45PM -0700, Greg KH wrote:
> On Tue, Jul 31, 2007 at 12:51:37PM -0700, Kees Cook wrote:
> > I proposed the change below while Kay and Scott were at GUADEC, and
> > it seems the response was generally negative, but without any better
> > suggestions.  I'd like to bring this up again, as I think this solution,
> > while being a bit of hack, should at least be forward-compatible if/when
> > v4l sysfs stuff is sorted out better.
> 
> Why can't we just fix the kernel code to do the right thing?

Because I'm more familiar with writing udev rules than coding sysfs?  :)

Mostly I have no idea what the scope of the changes are for v4l sysfs
fixes.  It's not clear to me if each subdriver needs to be fixed, or if
it's just a matter of getting the core of v4l fixed up.

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?

By my estimation, the v4l sysfs is missing a "driver" linkage?  I'm not
entirely sure where to start looking.

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Greg KH]

On Wed, Aug 01, 2007 at 02:31:30PM -0700, Kees Cook wrote:
> On Wed, Aug 01, 2007 at 01:52:45PM -0700, Greg KH wrote:
> > On Tue, Jul 31, 2007 at 12:51:37PM -0700, Kees Cook wrote:
> > > I proposed the change below while Kay and Scott were at GUADEC, and
> > > it seems the response was generally negative, but without any better
> > > suggestions.  I'd like to bring this up again, as I think this solution,
> > > while being a bit of hack, should at least be forward-compatible if/when
> > > v4l sysfs stuff is sorted out better.
> > 
> > Why can't we just fix the kernel code to do the right thing?
> 
> Because I'm more familiar with writing udev rules than coding sysfs?  :)
> 
> Mostly I have no idea what the scope of the changes are for v4l sysfs
> fixes.  It's not clear to me if each subdriver needs to be fixed, or if
> it's just a matter of getting the core of v4l fixed up.
> 
> 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?

> 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?

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

Re: work-around for video4linux sysfs

[Kees Cook]

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.  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.

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.

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Greg KH]

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

Re: work-around for video4linux sysfs

[Kees Cook]

On Wed, Aug 01, 2007 at 03:39:24PM -0700, Greg KH wrote:
> 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 :(

Right, and since there wasn't a common serial number, best I saw was
the path_id stuff.  :)

> Ick, that sounds messy :(

Very, yes.

> Can you show me the sysfs representation for the v4l devices you have?

Sure:

/sys/class/video4linux/video0# tree
.
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:08.0/0000:01:06.0
|-- name
|-- subsystem -> ../../../class/video4linux
`-- uevent

/sys/class/video4linux/video1# tree
.
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:08.0/0000:01:07.0
|-- name
|-- subsystem -> ../../../class/video4linux
`-- uevent

# udevinfo -a -p $(udevinfo --query path -n /dev/video0)

  looking at device '/class/video4linux/video0':
    KERNEL="video0"
    SUBSYSTEM="video4linux"
    DRIVER=""
    ATTR{name}="cx88_0_ video _pcHDTV HD3000 HD"
    ATTR{dev}="81:0"

  looking at parent device '/devices/pci0000:00/0000:00:08.0/0000:01:06.0':
    KERNELS="0000:01:06.0"
    SUBSYSTEMS="pci"
    DRIVERS="cx8800"
    ATTRS{msi_bus}=""
    ATTRS{broken_parity_status}="0"
    ATTRS{enable}="1"
    ATTRS{modalias}="pci:v000014F1d00008800sv00007063sd00003000bc04sc00i00"
    ATTRS{local_cpus}="ff"
    ATTRS{irq}="20"
    ATTRS{class}="0x040000"
    ATTRS{subsystem_device}="0x3000"
    ATTRS{subsystem_vendor}="0x7063"
    ATTRS{device}="0x8800"
    ATTRS{vendor}="0x14f1"

  looking at parent device '/devices/pci0000:00/0000:00:08.0':
    KERNELS="0000:00:08.0"
    SUBSYSTEMS="pci"
    DRIVERS=""
    ATTRS{msi_bus}="1"
    ATTRS{broken_parity_status}="0"
    ATTRS{enable}="1"
    ATTRS{modalias}="pci:v000010DEd0000006Csv00000000sd00000000bc06sc04i00"
    ATTRS{local_cpus}="ff"
    ATTRS{irq}="0"
    ATTRS{class}="0x060400"
    ATTRS{subsystem_device}="0x0000"
    ATTRS{subsystem_vendor}="0x0000"
    ATTRS{device}="0x006c"
    ATTRS{vendor}="0x10de"

  looking at parent device '/devices/pci0000:00':
    KERNELS="pci0000:00"
    SUBSYSTEMS=""
    DRIVERS=""

# udevinfo -a -p $(udevinfo --query path -n /dev/video1)

Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/class/video4linux/video1':
    KERNEL="video1"
    SUBSYSTEM="video4linux"
    DRIVER=""
    ATTR{name}="ivtv0 encoder MPEG"
    ATTR{dev}="81:1"

  looking at parent device '/devices/pci0000:00/0000:00:08.0/0000:01:07.0':
    KERNELS="0000:01:07.0"
    SUBSYSTEMS="pci"
    DRIVERS="ivtv"
    ATTRS{msi_bus}=""
    ATTRS{broken_parity_status}="0"
    ATTRS{enable}="1"
    ATTRS{modalias}="pci:v00004444d00000016sv00000070sd00004009bc04sc00i00"
    ATTRS{local_cpus}="ff"
    ATTRS{irq}="21"
    ATTRS{class}="0x040000"
    ATTRS{subsystem_device}="0x4009"
    ATTRS{subsystem_vendor}="0x0070"
    ATTRS{device}="0x0016"
    ATTRS{vendor}="0x4444"

  looking at parent device '/devices/pci0000:00/0000:00:08.0':
    KERNELS="0000:00:08.0"
    SUBSYSTEMS="pci"
    DRIVERS=""
    ATTRS{msi_bus}="1"
    ATTRS{broken_parity_status}="0"
    ATTRS{enable}="1"
    ATTRS{modalias}="pci:v000010DEd0000006Csv00000000sd00000000bc06sc04i00"
    ATTRS{local_cpus}="ff"
    ATTRS{irq}="0"
    ATTRS{class}="0x060400"
    ATTRS{subsystem_device}="0x0000"
    ATTRS{subsystem_vendor}="0x0000"
    ATTRS{device}="0x006c"
    ATTRS{vendor}="0x10de"

  looking at parent device '/devices/pci0000:00':
    KERNELS="pci0000:00"
    SUBSYSTEMS=""
    DRIVERS=""


Note that the ATTR{name} is the truncated non-standard description I was
talking about in the earlier email.  e.g. during boot init we see things
like:

[   45.576276] ivtv0: Initialized Hauppauge WinTV PVR-250, card #0
...
[   47.172046] CORE cx88[0]: subsystem: 7063:3000, board: pcHDTV HD3000 HDTV [card"]

My wishlist would be to get the "board name" somewhere into the v4l
drivers, but that requires more code diving than I have time for at the
moment.  :)

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Greg KH]

On Wed, Aug 01, 2007 at 04:14:18PM -0700, Kees Cook wrote:
> On Wed, Aug 01, 2007 at 03:39:24PM -0700, Greg KH wrote:
> > 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 :(
> 
> Right, and since there wasn't a common serial number, best I saw was
> the path_id stuff.  :)

Ok, in looking at the sysfs tree, which seems pretty sane, I don't know
of any other way to try to implement this, so I have no objection to
your changes.

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

Re: work-around for video4linux sysfs

[Kees Cook]

On Wed, Aug 01, 2007 at 04:28:38PM -0700, Greg KH wrote:
> Ok, in looking at the sysfs tree, which seems pretty sane, I don't know
> of any other way to try to implement this, so I have no objection to
> your changes.

Neato, thanks.  Who has commit access?  ;)

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

On 8/2/07, Kees Cook <kees@outflux.net> wrote:
> On Wed, Aug 01, 2007 at 04:28:38PM -0700, Greg KH wrote:
> > Ok, in looking at the sysfs tree, which seems pretty sane, I don't know
> > of any other way to try to implement this, so I have no objection to
> > your changes.
>
> Neato, thanks.  Who has commit access?  ;)

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.
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.

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

Re: work-around for video4linux sysfs

[Kees Cook]

Hi Kay,

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

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.  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).

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-")

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?

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

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

Re: work-around for video4linux sysfs

[Linas Vepstas]

On Fri, Aug 03, 2007 at 12:30:12AM +0200, Kay Sievers wrote:
> On Thu, 2007-08-02 at 07:05 -0700, Kees Cook wrote:
> > 
> > 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

I haven't tried recently, but in the "good old days", I used to
get bitten hard every time I shuffled around the PCI cards from
one slot to another, to make room for one more.

> SCSI uses stable interface and port numbers here. 

Hehe. SCSI LUN's can change when one is adding and removing failed 
disks, or shuffling around so that one can re-cable.  That was
another source of heartburn.

The only viable solution is to work off some unique ID on the 
device (e.g. a MAC address on ethernet).

--linas


-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

On Thu, 2007-08-02 at 17:39 -0500, Linas Vepstas wrote:
> On Fri, Aug 03, 2007 at 12:30:12AM +0200, Kay Sievers wrote:
> > On Thu, 2007-08-02 at 07:05 -0700, Kees Cook wrote:
> > > 
> > > 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
> 
> I haven't tried recently, but in the "good old days", I used to
> get bitten hard every time I shuffled around the PCI cards from
> one slot to another, to make room for one more.

"Shuffling around" is absolutly expected to change "by-path" links,
that's actually the correct and expected behavior. :)
There are by-id links, which are independent of the
path/port/slot/numbers. For block devices there are by-uuid and
by-label, which don't change by moving hardware around.

> > SCSI uses stable interface and port numbers here. 
> 
> Hehe. SCSI LUN's can change when one is adding and removing failed 
> disks, or shuffling around so that one can re-cable.  That was
> another source of heartburn.

Same here, by-path must change if the path to the hardware changes.
Depending on the setup, these links are more or less useful than the
links based on the content or properties owned by the hardware.

> The only viable solution is to work off some unique ID on the 
> device (e.g. a MAC address on ethernet).

The MAC is fine for most of the simple setups, yes. But there are lots
of cases where they just don't work. There are whole architectures in
the kernel which only use random MAC addresses and you need to fall back
to the path to the device.

Oh, and there are a lot of properties on other subsystems which can be
used to create reliable device names. Depending on the actual hardware
or the setup, there is no general rule which category of links is more
viable than the other, just look what /dev/disk offers, they are all
needed.

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

Re: work-around for video4linux sysfs

[Kees Cook]

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, which I worked around in the original patch.  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.  :(

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

+# 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.

-Kees

[1] http://ivtvdriver.org/index.php/FAQ

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

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

Re: work-around for video4linux sysfs

[Kees Cook]

On Tue, Aug 07, 2007 at 11:24:34AM +0200, Kay Sievers wrote:
> > 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 is the best place for me to start learning how to plumb such a
thing into v4l?  I haven't poked at sysfs from kernel space before, and
as I understand, the v4l driver development is rather fragmented, so I
guess I'm asking both a "technical howto" and a "political howto" for
getting it done.

I agree, though, this is the only correct approach.

> 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.

Agreed; that was just a hack for the most common use-case I had
encountered with the v4l link collisions: for ivtv, MythTV always wants the
encoder devices, which happens to be the first one instantiated.

Thanks for dealing with me and this mess.  :)

-Kees

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

On Tue, 2007-08-07 at 12:36 -0700, Kees Cook wrote:
> On Tue, Aug 07, 2007 at 11:24:34AM +0200, Kay Sievers wrote:
> > > 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 is the best place for me to start learning how to plumb such a
> thing into v4l?  I haven't poked at sysfs from kernel space before, and
> as I understand, the v4l driver development is rather fragmented, so I
> guess I'm asking both a "technical howto" and a "political howto" for
> getting it done.

Look at drivers/media/video/videodev.c how the "name" attribute is
created. There should probably be common "function" names added to
the v4l core which are just referenced by the drivers, like the
defines for the device type in include/media/v4l2-dev.h which are
replaced by strings in drivers/media/video/videodev.c.

> I agree, though, this is the only correct approach.
> 
> > 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.
> 
> Agreed; that was just a hack for the most common use-case I had
> encountered with the v4l link collisions: for ivtv, MythTV always wants the
> encoder devices, which happens to be the first one instantiated.

Yeah, I see the problem, and it's time to solve it. Maybe you can try to
add the stuff to the drivers you have access to the hardware, and we can
come up with a working prototype, propose that to the v4l maintainer(s)
and convert the other drivers step by step. Persistent names would just
rely on that feature to be added to the driver for devices with multiple
nodes of the same type.

Btw, what does:
  grep . /sys/class/video4linux/*/*
print on your box? If you have access to the device with the multiple
nodes.

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

Re: work-around for video4linux sysfs

[Kees Cook]

Hi Kay,

On Wed, Aug 08, 2007 at 12:58:43AM +0200, Kay Sievers wrote:
> Look at drivers/media/video/videodev.c how the "name" attribute is
> created. There should probably be common "function" names added to
> the v4l core which are just referenced by the drivers, like the
> defines for the device type in include/media/v4l2-dev.h which are
> replaced by strings in drivers/media/video/videodev.c.

Okay, thanks.  I'll try to find some time to investigate this.

> Yeah, I see the problem, and it's time to solve it. Maybe you can try to
> add the stuff to the drivers you have access to the hardware, and we can
> come up with a working prototype, propose that to the v4l maintainer(s)
> and convert the other drivers step by step. Persistent names would just
> rely on that feature to be added to the driver for devices with multiple
> nodes of the same type.

Sure, that sounds right.

> Btw, what does:
>   grep . /sys/class/video4linux/*/*
> print on your box? If you have access to the device with the multiple
> nodes.

$ grep . /sys/class/video4linux/*/* 2>/dev/null
/sys/class/video4linux/radio0/dev:81:64
/sys/class/video4linux/radio0/name:cx88[0] radio (pcHDTV HD3000 HD
/sys/class/video4linux/vbi0/dev:81:224
/sys/class/video4linux/vbi0/name:cx88[0] vbi (pcHDTV HD3000 HDTV
/sys/class/video4linux/vbi1/dev:81:225
/sys/class/video4linux/vbi1/name:ivtv0 encoder VBI
/sys/class/video4linux/video0/dev:81:0
/sys/class/video4linux/video0/name:cx88[0] video (pcHDTV HD3000 HD
/sys/class/video4linux/video1/dev:81:1
/sys/class/video4linux/video1/name:ivtv0 encoder MPEG
/sys/class/video4linux/video24/dev:81:24
/sys/class/video4linux/video24/name:ivtv0 encoder PCM audio
/sys/class/video4linux/video32/dev:81:32
/sys/class/video4linux/video32/name:ivtv0 encoder YUV

How's that for a mess?  ;)

Thanks again,

-Kees

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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

Re: work-around for video4linux sysfs

[Kay Sievers]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Tue, 2007-08-07 at 16:18 -0700, Kees Cook wrote:
> On Wed, Aug 08, 2007 at 12:58:43AM +0200, Kay Sievers wrote:
> > Look at drivers/media/video/videodev.c how the "name" attribute is
> > created. There should probably be common "function" names added to
> > the v4l core which are just referenced by the drivers, like the
> > defines for the device type in include/media/v4l2-dev.h which are
> > replaced by strings in drivers/media/video/videodev.c.
> 
> Okay, thanks.  I'll try to find some time to investigate this.

Try the attached patch as a start. It adds a "function" attribute to
every v4l device. You need to add the classification to the drivers you
use, to see if that will work for you.

I added V4L2_FN_VIDEO_CAP to my ancient webcam:
  $ grep . /sys/class/video4linux/*/*
  /sys/class/video4linux/video0/bridge:OV511+
  /sys/class/video4linux/video0/brightness:126
  /sys/class/video4linux/video0/contrast:86
  /sys/class/video4linux/video0/custom_id:21
  /sys/class/video4linux/video0/dev:81:0
  /sys/class/video4linux/video0/exposure:0
  /sys/class/video4linux/video0/function:video-cap
  /sys/class/video4linux/video0/hue:128
  /sys/class/video4linux/video0/model:Creative Labs WebCam 3
  /sys/class/video4linux/video0/name:OV511 USB Camera
  /sys/class/video4linux/video0/saturation:192
  /sys/class/video4linux/video0/sensor:OV7620

Good luck,  
Kay


[-- Attachment #2: v4l-function-attr.patch --]
[-- Type: text/x-patch, Size: 5187 bytes --]

diff --git a/drivers/media/video/ov511.c b/drivers/media/video/ov511.c
index e5edff1..511d094 100644
--- a/drivers/media/video/ov511.c
+++ b/drivers/media/video/ov511.c
@@ -4668,6 +4668,7 @@ static struct video_device vdev_template = {
 	.owner =	THIS_MODULE,
 	.name =		"OV511 USB Camera",
 	.type =		VID_TYPE_CAPTURE,
+	.function = 	V4L2_FN_VIDEO_CAP,
 	.hardware =	VID_HARDWARE_OV511,
 	.fops =		&ov511_fops,
 	.release =	video_device_release,
diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-common.c
index d2915d3..84ded35 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -247,6 +247,45 @@ int v4l2_prio_check(struct v4l2_prio_state *global, enum v4l2_priority *local)
 	return 0;
 }
 
+/*
+ * Exports "function" string to userspace to identify the type of device
+ * if multiple streams are available for a single device.
+ *
+ * Types/string names should be reused if possible, instead of adding
+ * new very device specific types, they must _uniquely_ identify all
+ * streams belonging to the _same_ device though.
+ *
+ * No single device must export multiple streams with the same function
+ * string, because userspace this to find the correct device node.
+ *
+ * Unlike the free-text "name", it must be an easily machine useable
+ * string containing only [a-z0-9._-] characters.
+ *
+ * Strings must not change without a valid reason, they are part of the
+ * sysfs ABI.
+ *
+ */
+static const char *v4l2_function_type_names[] = {
+	[V4L2_FN_UNDEFINED]		= "undefined",
+	[V4L2_FN_VIDEO_CAP]		= "video-cap",
+	[V4L2_FN_VIDEO_OUT]		= "video-out",
+	[V4L2_FN_MPEG_CAP]		= "mpeg-cap",
+	[V4L2_FN_MPEG_OUT]		= "mpeg-out",
+	[V4L2_FN_YUV_CAP]		= "yuv-cap",
+	[V4L2_FN_YUV_OUT]		= "yuv-out",
+	[V4L2_FN_VBI_CAP]		= "vbi-cap",
+	[V4L2_FN_VBI_OUT]		= "vbi-out",
+	[V4L2_FN_PCM_CAP]		= "pcm-cap",
+	[V4L2_FN_PCM_OUT]		= "pcm-out",
+};
+
+const char *v4l2_function_name(enum v4l2_function_type function)
+{
+	if (function >= 0 && function < ARRAY_SIZE(v4l2_function_type_names))
+		return v4l2_function_type_names[function];
+	printk(KERN_ERR "v4ls: unknown v4l2_function_type\n");
+	return "error";
+}
 
 /* ----------------------------------------------------------------- */
 /* some arrays for pretty-printing debug messages of enum types      */
diff --git a/drivers/media/video/videodev.c b/drivers/media/video/videodev.c
index b876aca..582773c 100644
--- a/drivers/media/video/videodev.c
+++ b/drivers/media/video/videodev.c
@@ -61,7 +61,12 @@ static ssize_t show_name(struct class_device *cd, char *buf)
 	return sprintf(buf,"%.*s\n",(int)sizeof(vfd->name),vfd->name);
 }
 
-static CLASS_DEVICE_ATTR(name, S_IRUGO, show_name, NULL);
+static ssize_t show_function(struct class_device *cd, char *buf)
+{
+	struct video_device *vfd = container_of(cd, struct video_device,
+								class_dev);
+	return sprintf(buf, "%s\n", v4l2_function_name(vfd->function));
+}
 
 struct video_device *video_device_alloc(void)
 {
@@ -89,8 +94,15 @@ static void video_release(struct class_device *cd)
 	vfd->release(vfd);
 }
 
+static struct class_device_attribute video_device_attrs[] = {
+	__ATTR(name, S_IRUGO, show_name, NULL),
+	__ATTR(function, S_IRUGO, show_function, NULL),
+	__ATTR_NULL
+};
+
 static struct class video_class = {
 	.name    = VIDEO_NAME,
+	.class_dev_attrs = video_device_attrs,
 	.release = video_release,
 };
 
@@ -1763,12 +1775,6 @@ int video_register_device(struct video_device *vfd, int type, int nr)
 		       __FUNCTION__);
 		goto fail_minor;
 	}
-	ret = class_device_create_file(&vfd->class_dev, &class_device_attr_name);
-	if (ret < 0) {
-		printk(KERN_ERR "%s: class_device_create_file 'name' failed\n",
-		       __FUNCTION__);
-		goto fail_classdev;
-	}
 
 #if 1
 	/* needed until all drivers are fixed */
@@ -1779,8 +1785,6 @@ int video_register_device(struct video_device *vfd, int type, int nr)
 #endif
 	return 0;
 
-fail_classdev:
-	class_device_unregister(&vfd->class_dev);
 fail_minor:
 	mutex_lock(&videodev_lock);
 	video_device[vfd->minor] = NULL;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index c66c8a3..d048d46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -138,6 +138,23 @@ enum v4l2_field {
 	 (field) == V4L2_FIELD_SEQ_TB ||\
 	 (field) == V4L2_FIELD_SEQ_BT)
 
+/* Exports "function" string to userspace to identify type of device */
+enum v4l2_function_type {
+	V4L2_FN_UNDEFINED,
+	V4L2_FN_VIDEO_CAP,
+	V4L2_FN_VIDEO_OUT,
+	V4L2_FN_MPEG_CAP,
+	V4L2_FN_MPEG_OUT,
+	V4L2_FN_YUV_CAP,
+	V4L2_FN_YUV_OUT,
+	V4L2_FN_VBI_CAP,
+	V4L2_FN_VBI_OUT,
+	V4L2_FN_PCM_CAP,
+	V4L2_FN_PCM_OUT,
+};
+
+extern const char *v4l2_function_name(enum v4l2_function_type function);
+
 enum v4l2_buf_type {
 	V4L2_BUF_TYPE_VIDEO_CAPTURE        = 1,
 	V4L2_BUF_TYPE_VIDEO_OUTPUT         = 2,
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index d62847f..0141b6c 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -93,6 +93,7 @@ struct video_device
 	char name[32];
 	int type;       /* v4l1 */
 	int type2;      /* v4l2 */
+	enum v4l2_function_type function; /* sysfs string */
 	int hardware;
 	int minor;
 

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 226 bytes --]

_______________________________________________
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

Re: work-around for video4linux sysfs

[Kees Cook]

Hi Kay,

On Wed, Aug 08, 2007 at 12:48:59PM +0200, Kay Sievers wrote:
> Try the attached patch as a start. It adds a "function" attribute to
> every v4l device. You need to add the classification to the drivers you
> use, to see if that will work for you.

Oh hey, very cool.  Thanks for doing this!  I will need some time to
build a replacement kernel for my MythTV system -- I need to schedule it
around the pending recordings, etc.  ;)

I'll get the ivtv and pcHDTV drivers adjusted to use the new attribute.

Thanks!

-Kees

-- 
Kees Cook                                            @outflux.net

-------------------------------------------------------------------------
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