libudev, a question about the enumerate API.

libudev, a question about the enumerate API.

[Antonio Ospite]

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

Hi,

in my attempts to handle leds setting and usb pairing for the Sixaxis
controller I had to fight with libudev a little bit, eventually I
succeeded in what I wanted to achieve but I still have some questions
about the libudev API, so here I am.

This is basically the layout for the device:

4-1:1.0/
|-- 0003:054C:0268.000C  (hid device)
|   |-- hidraw
|   |   `-- hidraw1
|   `-- uevent  (which tells me HID_PHYS)
|
`-- input
    `-- input17
        |-- js0
        `-- phys

I needed to get the hidraw device node, and the js device number, the
two sibling devices (from hid and input subsystem) can be matched using
the 'phys' property.

This is what I do now:
 0. Monitor with a filter matching the "hidraw" subsystem.
 1. When a matching device is connected we get the "hidraw" device.
 2. Go up to its "hid" parent device and check it is actually a
    Sixaxis (using HID_NAME), if not GOTO 1.
 3. Store the hidraw device node for later use
 4. Store the HID_PHYS value in order to look for the matching joystick.
 5. Enumerate the joystick devices with the sysname filter "js*"
 6. For each joystick:
    a. Go up to its input parent device
    b. Check that the phys attribute matches HID_PHYS,
       if so, store the joystick device number.
 7. Set leds
 8. If the Sixaxis is connected via USB do the cable pairing.

My doubt is about 5. and 6a.: I have go deep in the hierarchy down to
the js0 leaf device and then I have to go up one level to get the
input device, naively I would have done the contrary:
 5'. Enumerate the input devices such that phys == HID_PHYS
 6'. Enumerate the devices _below_ the input device from 5'. looking
     for the jsX device.

But this is not possible because the enumerate API is designed to start
always from the root of /sys.

Finally the question: why the enumerate API in libudev does not allow
enumerating only from a _subtree_? Has that been designed this way to
keep the API simple, or because it is not considered useful?

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: libudev, a question about the enumerate API.

[Kay Sievers]

On Wed, Feb 23, 2011 at 23:50, Antonio Ospite <ospite@studenti.unina.it> wrote:
> Hi,
>
> in my attempts to handle leds setting and usb pairing for the Sixaxis
> controller I had to fight with libudev a little bit, eventually I
> succeeded in what I wanted to achieve but I still have some questions
> about the libudev API, so here I am.
>
> This is basically the layout for the device:
>
> 4-1:1.0/
> |-- 0003:054C:0268.000C  (hid device)
> |   |-- hidraw
> |   |   `-- hidraw1
> |   `-- uevent  (which tells me HID_PHYS)
> |
> `-- input
>    `-- input17
>        |-- js0
>        `-- phys
>
> I needed to get the hidraw device node, and the js device number, the
> two sibling devices (from hid and input subsystem) can be matched using
> the 'phys' property.
>
> This is what I do now:
>  0. Monitor with a filter matching the "hidraw" subsystem.
>  1. When a matching device is connected we get the "hidraw" device.
>  2. Go up to its "hid" parent device and check it is actually a
>    Sixaxis (using HID_NAME), if not GOTO 1.
>  3. Store the hidraw device node for later use
>  4. Store the HID_PHYS value in order to look for the matching joystick.
>  5. Enumerate the joystick devices with the sysname filter "js*"
>  6. For each joystick:
>    a. Go up to its input parent device
>    b. Check that the phys attribute matches HID_PHYS,
>       if so, store the joystick device number.
>  7. Set leds
>  8. If the Sixaxis is connected via USB do the cable pairing.
>
> My doubt is about 5. and 6a.: I have go deep in the hierarchy down to
> the js0 leaf device and then I have to go up one level to get the
> input device, naively I would have done the contrary:
>  5'. Enumerate the input devices such that phys = HID_PHYS
>  6'. Enumerate the devices _below_ the input device from 5'. looking
>     for the jsX device.
>
> But this is not possible because the enumerate API is designed to start
> always from the root of /sys.
>
> Finally the question: why the enumerate API in libudev does not allow
> enumerating only from a _subtree_? Has that been designed this way to
> keep the API simple, or because it is not considered useful?

The usual enumeration in udev never uses the device tree in
/sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
have something to enumerate all child devices of a given device. It's
not simple, but could be made working.

Kay

Re: libudev, a question about the enumerate API.

[Alan Ott]

On 03/07/2011 10:27 AM, Kay Sievers wrote:
> The usual enumeration in udev never uses the device tree in
> /sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
> have something to enumerate all child devices of a given device. It's
> not simple, but could be made working.
>    

Hi Kay,

The documentation in Documentation/sysfs-rules.txt seems to warn against 
using /sys/class and sys/bus:

- devices are only "devices"
   There is no such thing like class-, bus-, physical devices,
   interfaces, and such that you can rely on in userspace. Everything is
   just simply a "device". Class-, bus-, physical, ... types are just
   kernel implementation details which should not be expected by
   applications that look for devices in sysfs.

...
       - all elements of a devpath must be real directories. Symlinks
         pointing to /sys/devices must always be resolved to their real
         target and the target path must be used to access the device.
         That way the devpath to the device matches the devpath of the
         kernel used at event time.
       - using or exposing symlink values as elements in a devpath string
         is a bug in the application

...

       - accessing attributes reached by a symlink pointing to another 
device,
         like the "device"-link, is a bug in the application

...

- Hierarchy in a single device tree
   There is only one valid place in sysfs where hierarchy can be examined
   and this is below: /sys/devices.

and more...

I figured that this document was probably out of date, since even 
libudev uses /sys/class. What's your take on this document?

Alan.

Re: libudev, a question about the enumerate API.

[Kay Sievers]

On Mon, Mar 7, 2011 at 17:01, Alan Ott <alan@signal11.us> wrote:
> On 03/07/2011 10:27 AM, Kay Sievers wrote:
>>
>> The usual enumeration in udev never uses the device tree in
>> /sys/devices/, only the subsystem lists /sys/{class,bus}/. We could
>> have something to enumerate all child devices of a given device. It's
>> not simple, but could be made working.

> The documentation in Documentation/sysfs-rules.txt seems to warn against
> using /sys/class and sys/bus:
>
> - devices are only "devices"
>  There is no such thing like class-, bus-, physical devices,
>  interfaces, and such that you can rely on in userspace. Everything is
>  just simply a "device". Class-, bus-, physical, ... types are just
>  kernel implementation details which should not be expected by
>  applications that look for devices in sysfs.
>
> ...
>      - all elements of a devpath must be real directories. Symlinks
>        pointing to /sys/devices must always be resolved to their real
>        target and the target path must be used to access the device.
>        That way the devpath to the device matches the devpath of the
>        kernel used at event time.
>      - using or exposing symlink values as elements in a devpath string
>        is a bug in the application
>
> ...
>
>      - accessing attributes reached by a symlink pointing to another device,
>        like the "device"-link, is a bug in the application
>
> ...
>
> - Hierarchy in a single device tree
>  There is only one valid place in sysfs where hierarchy can be examined
>  and this is below: /sys/devices.
>
> and more...
>
> I figured that this document was probably out of date, since even libudev
> uses /sys/class. What's your take on this document?

I wrote that document. :) It's partly out-of-date, but this is still true.

Udev, since quite some years, even the old and dead HAL supports
/sys/subsystem/ already, which is not in the kernel today, but might
be soon.

If that directory is available, /sys/{class,bus}/ will not be looked at:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=libudev/libudev-enumerate.c;h\x128813c7d618717690f79d0eca82776a6c4fa011;hb=HEAD#l776

Kay