Bug 1283386 - udev_device_get_sysattr_list entry and udev_device_get_sysattr_value do not agree
udev_device_get_sysattr_list entry and udev_device_get_sysattr_value do not a...
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: systemd-maint
Depends On:
  Show dependency treegraph
Reported: 2015-11-18 15:48 EST by mulhern
Modified: 2015-11-25 13:22 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-25 13:15:30 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description mulhern 2015-11-18 15:48:22 EST
Description of problem:

At first I thought that udev_device_get_sysattr_list_entry returned a superset of the keys that udev_device_get_sysattr_value can find values for. That made some kind of sense, because udev_device_get_sysattr_list_entry finds file names and does not try to read there contents, that's udev_device_get_sysattr_value's job. But now, I find that udev_device_get_sysattr_value can often look up values that have no corresponding keys in the list returned by udev_device_get_sysattr_list_entry.

So the best that one can say is that the intersection of the strings returned by udev_device_get_sysattr_list_entry and of the strings for which udev_device_get_sysattr_value returns a non-NULL value is very likely to be non-empty.

It seems like having the keys returned by udev_device_get_sysattr_list_entry be a superset of the keys that can be evaluated by udev_device_get_sysattr_value would be the only sensible way to go to get a useful relationship going between these two related methods.

Version-Release number of selected component (if applicable):

Installed Packages
Name        : systemd
Arch        : x86_64
Version     : 219
Release     : 19.el7
Size        : 21 M
Repo        : installed
From repo   : RHEL-7-RTT

How reproducible:


Steps to Reproduce:
1. Get the list of keys using udev_device_get_sysattr_list_entry.
2. Notice that bdi is a key with no corresponding value (it's a directory)
3. Notice that bdi/max_ratio is looked up fine by udev_device_get_sysattr_value but is not in the list of keys.
4. Notice that 'dm/name' is is looked up fine but is not in the list of keys and nor is 'dm' either.

Actual results:

A very unclear relationship between result of udev_device_get_sysattr_list_entry and udev_device_get_sysattr_value.

Expected results:

I was lead to believe originally that there was a superset relationship between the keys returned by udev_device_get_sysattr_list_entry and those that
udev_device_get_sysattr_value could get a value for.

Additional info:
Comment 2 mulhern 2015-11-25 13:10:51 EST
And the answer to what is actually going on:

libudev just reads the contents of the directory corresponding to the device.
The keys are the names of all files in the directory that are plain files or links.

When libudev looks up values it interprets the "key" as a path relative to the sysfs
directory. If that path is a link, then for the special names in
{'driver', 'subsystem', 'module'} it returns the value of the basename of the path
that is the target of the link. For all other links it returns NULL. For directories
it returns NULL. For regular files, it reads the contents of the file.

This explains why 'dm' is not an 'available' attribute, why 'bdi' is, why the value of
'bdi' is always NULL, and why subsystem is an "available" attribute, with, generally,
a non-NULL value.

There is probably nothing to be done about this. Perhaps a comment on udev_device_get_sysattr_list_entry defining 'available' might be worth a try.
Comment 3 mulhern 2015-11-25 13:15:30 EST
I don't think it would repay the effort, though.

Note You need to log in before you can comment on or make changes to this bug.