Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1075902[details]
Simple test file illustrating an example device
Description of problem:
udev_device_get_sysattr_list_entry returns a list of attribute, value pairs.
The values are NULL, the attributes are said to be "available".
From the docs:
"""
Retrieve the list of available sysattrs, with value being empty; This just return all available sysfs attributes for a particular device without reading their values.
"""
I dunno what "available" is supposed to mean, but if these attributes are
further looked up by "udev_device_get_sysattr_value" they may have no value,
i.e., this method may return NULL. (This is not the same as having a value
like the empty string, which fits the specification just fine.)
Version-Release number of selected component (if applicable):
Any.
How reproducible:
Consistently, for a given device.
Steps to Reproduce:
1. Loop over all devices returned by udevadm.
2. List the attributes using udev_device_get_sysattr_list_entry().
3. Look up the listed attributes using udev_device_get_sysattr_value(). Observe that some of these attributes are NULL.
Actual results:
Some "available" attributes have no values. Generally speaking, these attributes seem to be symlinks to directories. It is not true that all attributes that correspond to symlinks to directories have no value, only some.
Expected results:
"Available" attributes should have a value or documentation should define clearly that "available" means fits some criteria which does not necessarily include actually having a value.
Additional info:
It is normal to think of attribute name/value pairs as being like keys in a map.
If they are not, that is, if a key can simultaneously be in the map and not be
in the map, that should get better documentation then by the single word "available".
Also, in documentation, the ';' is followed by a capital letter, should be lowercase.
Output of new.c on my Fedora desktop. This is just an example, similar things
happen on my RHEL 7.2 box.
[mulhern@localhost reproducers]$ ./a.out
udev_list_entry_get_value()
Correct behavior, values are not obtained.
adr: (null)
path: (null)
subsystem: (null)
uevent: (null)
physical_node: (null)
udev_device_get_sysattr_value()
Incorrect behavior; physical_node should have a value.
adr: 0x00000000
path: \_SB_.PCI0.EHC2.HUBN
subsystem: acpi
uevent:
physical_node: (null)
udev_device_get_sysattr_value(bogus)
correct behavior, value of non-existant attribute is null.
bogus: (null)
Should be like the first.
adr: (null)
path: (null)
subsystem: (null)
uevent: (null)
physical_node: (null)
The attached file printed SURPRISE a few times on both systems, indicating that some of the attributes with no value were not symlinked directories. What characteristics they do have I do not know.
Given that I have an answer to my question in bz#1267584 this bug can not be said to block it. The only outstanding issue really is that these methods should be documented better, to avoid the same confusion arising for someone else in the future.
Probably a thorough understanding of the architecture and underlying assumptions of this component would allow a user to infer the most important consequences of the relations between the methods involved from the existing documentation.
Created attachment 1075902 [details] Simple test file illustrating an example device Description of problem: udev_device_get_sysattr_list_entry returns a list of attribute, value pairs. The values are NULL, the attributes are said to be "available". From the docs: """ Retrieve the list of available sysattrs, with value being empty; This just return all available sysfs attributes for a particular device without reading their values. """ I dunno what "available" is supposed to mean, but if these attributes are further looked up by "udev_device_get_sysattr_value" they may have no value, i.e., this method may return NULL. (This is not the same as having a value like the empty string, which fits the specification just fine.) Version-Release number of selected component (if applicable): Any. How reproducible: Consistently, for a given device. Steps to Reproduce: 1. Loop over all devices returned by udevadm. 2. List the attributes using udev_device_get_sysattr_list_entry(). 3. Look up the listed attributes using udev_device_get_sysattr_value(). Observe that some of these attributes are NULL. Actual results: Some "available" attributes have no values. Generally speaking, these attributes seem to be symlinks to directories. It is not true that all attributes that correspond to symlinks to directories have no value, only some. Expected results: "Available" attributes should have a value or documentation should define clearly that "available" means fits some criteria which does not necessarily include actually having a value. Additional info: It is normal to think of attribute name/value pairs as being like keys in a map. If they are not, that is, if a key can simultaneously be in the map and not be in the map, that should get better documentation then by the single word "available". Also, in documentation, the ';' is followed by a capital letter, should be lowercase.