Figuring out devnodes from a usb device

Figuring out devnodes from a usb device

[Felipe Balbi]

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

Hi all,

I'm trying to figure out how I could find all devnodes related to a USB
device. For example, if I attach a usb mass storage device I want to
figure out which /dev/sdXX I'm supposed to use when trying to read/write
to that particular device. Similarly for ACM, Network and all other devices.

Is there any way to achieve that with libudev ? I tried using
udev_device_get_devlinks_list_entry() but that didn't help.

I'm attaching my current code which is a modifed version of a tutorial
from Alan Ott available at [1].

[1] http://www.signal11.us/oss/udev/

-- 
balbi

[-- Attachment #2: udev.c --]
[-- Type: text/x-c, Size: 1765 bytes --]

#include <libudev.h>
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
#include <unistd.h>

int main (void)
{
	struct udev *udev;
	struct udev_enumerate *enumerate;
	struct udev_list_entry *devices, *dev_list_entry;
	struct udev_device *dev;

	/* Create the udev object */
	udev = udev_new();
	if (!udev) {
		printf("Can't create udev\n");
		exit(1);
	}

	/* Create a list of the devices in the 'hidraw' subsystem. */
	enumerate = udev_enumerate_new(udev);
	udev_enumerate_add_match_subsystem(enumerate, "usb");
	udev_enumerate_scan_devices(enumerate);
	devices = udev_enumerate_get_list_entry(enumerate);

	/* For each item enumerated, print out its information.
	 * udev_list_entry_foreach is a macro which expands to
	 * a loop. The loop will be executed for each member in
	 * devices, setting dev_list_entry to a list entry
	 * which contains the device's path in /sys. */
	udev_list_entry_foreach(dev_list_entry, devices) {
		struct udev_list_entry		*links, *more_devs;
		const char *path;
		unsigned count = 0;

		/* Get the filename of the /sys entry for the device
		 * and create a udev_device object (dev) representing it */
		path = udev_list_entry_get_name(dev_list_entry);
		dev = udev_device_new_from_syspath(udev, path);
		links = udev_device_get_devlinks_list_entry(dev);

		udev_list_entry_foreach(more_devs, links) {
			struct udev_device	*other_dev;
			const char		*path;

			printf("dev #%d\n", count);
			count++;

			path = udev_list_entry_get_name(links);

			other_dev = udev_device_new_from_syspath(udev, path);

			printf("Device node path: %s\n", udev_device_get_devnode(other_dev));
		}

		udev_device_unref(dev);
	}

	/* Free the enumerator object */
	udev_enumerate_unref(enumerate);
	udev_unref(udev);

	return 0;       
}

Re: Figuring out devnodes from a usb device

[Greg KH]

On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
> Hi all,
> 
> I'm trying to figure out how I could find all devnodes related to a USB
> device.

That's hard, as there are lots of different types of USB devices.

It's like saying, "I want to find all devnodes for a PCI device" :)

> For example, if I attach a usb mass storage device I want to
> figure out which /dev/sdXX I'm supposed to use when trying to read/write
> to that particular device. Similarly for ACM, Network and all other devices.

For each type of device, you are going to have to do it differently.
And note that network devices don't have device nodes, so that makes it
harder to make a "general" case here.

> Is there any way to achieve that with libudev ?

Yes, but it's going to have to be type (i.e. class) specific.

> I tried using
> udev_device_get_devlinks_list_entry() but that didn't help.

You might not be looking at the "right" device.  You will have to go up
and down the device tree to find the correct one, depending on the type.
And what about devices with multiple interfaces, with different device
nodes (like the famous disk drive with a button on it, mass-storage and
a HID device).

good luck,

greg k-h

Re: Figuring out devnodes from a usb device

[Felipe Balbi]

On 08/03/2010 01:29 AM, Greg KH wrote:
Hi,

Thanks for you reply Greg

> On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
>> Hi all,
>>
>> I'm trying to figure out how I could find all devnodes related to a USB
>> device.
> 
> That's hard, as there are lots of different types of USB devices.
> 
> It's like saying, "I want to find all devnodes for a PCI device" :)
> 
>> For example, if I attach a usb mass storage device I want to
>> figure out which /dev/sdXX I'm supposed to use when trying to read/write
>> to that particular device. Similarly for ACM, Network and all other devices.
> 
> For each type of device, you are going to have to do it differently.
> And note that network devices don't have device nodes, so that makes it
> harder to make a "general" case here.
> 
>> Is there any way to achieve that with libudev ?
> 
> Yes, but it's going to have to be type (i.e. class) specific.
> 
>> I tried using
>> udev_device_get_devlinks_list_entry() but that didn't help.
> 
> You might not be looking at the "right" device.  You will have to go up
> and down the device tree to find the correct one, depending on the type.
> And what about devices with multiple interfaces, with different device
> nodes (like the famous disk drive with a button on it, mass-storage and
> a HID device).

those are the cases I was actually looking for. It's, then, practically
impossible to have a USBCV tool written for linux. There are missing
pieces on the kernel and even if the missing on the kernel is
implemented, it's gonna be difficult to find the devices we have o talk
to anyway. Unless we do the entire class implementation with pure libusb
or usbfs when e.g. testing MSC devices.

-- 
balbi

Re: Figuring out devnodes from a usb device

[Kay Sievers]

On Tue, Aug 3, 2010 at 09:28, Felipe Balbi <me@felipebalbi.com> wrote:
>>> For example, if I attach a usb mass storage device I want to
>>> figure out which /dev/sdXX I'm supposed to use when trying to read/write
>>> to that particular device. Similarly for ACM, Network and all other devices.
>>
>> For each type of device, you are going to have to do it differently.
>> And note that network devices don't have device nodes, so that makes it
>> harder to make a "general" case here.
>>
>>> Is there any way to achieve that with libudev ?

That's not provided by libudev, but would be possible to do.
It would need an 'udev enumerator' that starts at a given device,
and returns a list of all the children, which can be investigated
individually. All current 'enumerators' only operate on specific
properties of a device, not on parent-child relations.

All devices belonging to a specific USB device are sysfs child devices of
it. It's a simple tree you can walk. The child devices may have their own
device nodes (here: mouse2, event10), and may also belong to different
subsystems (here: input, hid).

That should work for all interfaces a device provides and which is
currently bound by a kernel driver. Note, that not all drivers use a device
node as the interface. No device node does never mean, that there is no
active driver.

  $ tree -d /sys/bus/usb/devices/5-2.1.2
  /sys/bus/usb/devices/5-2.1.2
  ├── 5-2.1.2:1.0
  │   ├── 0003:046D:C045.0009
  │   │   ├── driver -> ../../../../../../../../../bus/hid/drivers/generic-usb
  │   │   ├── power
  │   │   └── subsystem -> ../../../../../../../../../bus/hid
  │   ├── driver -> ../../../../../../../../bus/usb/drivers/usbhid
  │   ├── ep_81
  │   │   └── power
  │   ├── input
  │   │   └── input16
  │   │       ├── capabilities
  │   │       ├── device -> ../../../5-2.1.2:1.0
  │   │       ├── event10
  │   │       │   ├── device -> ../../input16
  │   │       │   ├── power
  │   │       │   └── subsystem -> ../../../../../../../../../../../class/input
  │   │       ├── id
  │   │       ├── mouse2
  │   │       │   ├── device -> ../../input16
  │   │       │   ├── power
  │   │       │   └── subsystem -> ../../../../../../../../../../../class/input
  │   │       ├── power
  │   │       └── subsystem -> ../../../../../../../../../../class/input
  │   ├── power
  │   └── subsystem -> ../../../../../../../../bus/usb
  ├── driver -> ../../../../../../../bus/usb/drivers/usb
  ├── ep_00
  │   └── power
  ├── power
  └── subsystem -> ../../../../../../../bus/usb

Kay

Re: Figuring out devnodes from a usb device

[Greg KH]

On Tue, Aug 03, 2010 at 10:28:18AM +0300, Felipe Balbi wrote:
> On 08/03/2010 01:29 AM, Greg KH wrote:
> Hi,
> 
> Thanks for you reply Greg
> 
> > On Sun, Aug 01, 2010 at 10:58:07PM +0300, Felipe Balbi wrote:
> >> Hi all,
> >>
> >> I'm trying to figure out how I could find all devnodes related to a USB
> >> device.
> > 
> > That's hard, as there are lots of different types of USB devices.
> > 
> > It's like saying, "I want to find all devnodes for a PCI device" :)
> > 
> >> For example, if I attach a usb mass storage device I want to
> >> figure out which /dev/sdXX I'm supposed to use when trying to read/write
> >> to that particular device. Similarly for ACM, Network and all other devices.
> > 
> > For each type of device, you are going to have to do it differently.
> > And note that network devices don't have device nodes, so that makes it
> > harder to make a "general" case here.
> > 
> >> Is there any way to achieve that with libudev ?
> > 
> > Yes, but it's going to have to be type (i.e. class) specific.
> > 
> >> I tried using
> >> udev_device_get_devlinks_list_entry() but that didn't help.
> > 
> > You might not be looking at the "right" device.  You will have to go up
> > and down the device tree to find the correct one, depending on the type.
> > And what about devices with multiple interfaces, with different device
> > nodes (like the famous disk drive with a button on it, mass-storage and
> > a HID device).
> 
> those are the cases I was actually looking for. It's, then, practically
> impossible to have a USBCV tool written for linux.

"USBCV"?

> There are missing pieces on the kernel and even if the missing on the
> kernel is implemented, it's gonna be difficult to find the devices we
> have o talk to anyway. Unless we do the entire class implementation
> with pure libusb or usbfs when e.g. testing MSC devices.

It's not impossible, just not something you can do without knowing the
type of device you are looking at.

thanks,

greg k-h

Re: Figuring out devnodes from a usb device

[Felipe Balbi]

Hi,

On 08/03/2010 10:53 PM, Greg KH wrote:
> "USBCV"?

USB Command Verifier. The tool used on USB Certification, well of them.

> It's not impossible, just not something you can do without knowing the
> type of device you are looking at.

as long as I can believe on the USB Descriptors that shouldn't be so
difficult. Just check device descriptor and interface descriptors to
figure out which kind of device(s) are we dealing with.

-- 
balbi

Re: Figuring out devnodes from a usb device

[Greg KH]

On Tue, Aug 03, 2010 at 11:20:41PM +0300, Felipe Balbi wrote:
> Hi,
> 
> On 08/03/2010 10:53 PM, Greg KH wrote:
> > "USBCV"?
> 
> USB Command Verifier. The tool used on USB Certification, well of them.

Good luck with that.  We tried to offer something like that many years
ago, but the effort fizzled out when the amount of work required was
determined.  But don't let me stop you from trying :)

> > It's not impossible, just not something you can do without knowing the
> > type of device you are looking at.
> 
> as long as I can believe on the USB Descriptors that shouldn't be so
> difficult. Just check device descriptor and interface descriptors to
> figure out which kind of device(s) are we dealing with.

How do you know what a vendor-specific device is doing?  Are you going
to be able to parse the HID descriptors to know what type of input
device(s) are present?

Look at what Kay provided, that will get you what you need.

good luck,

greg k-h

Re: Figuring out devnodes from a usb device

[Felipe Balbi]

Hi,

On 08/03/2010 11:32 PM, Greg KH wrote:
> How do you know what a vendor-specific device is doing?  Are you going
> to be able to parse the HID descriptors to know what type of input
> device(s) are present?

we can start simple. USBCV only runs the chapter 9 tests (which are
pretty much verifying if the device responds to standard requests
accordingly) which any device, and runs a set of MSC tests on MSC devices.

We can start with only that and improve later on.

-- 
balbi