Bug 1267584
Summary: | device.attributes.values likely to raise a KeyError | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | mulhern <amulhern> |
Component: | python-pyudev | Assignee: | Jaroslav Škarvada <jskarvad> |
Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.2 | CC: | bnater, lmiksik, qe-baseos-daemons, systemd-maint-list, systemd-maint, thozza |
Target Milestone: | rc | Keywords: | Rebase, Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1265315 | Environment: | |
Last Closed: | 2018-11-26 11:42:59 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
mulhern
2015-09-30 13:23:39 UTC
items(), iteritems(), and itervalues() all have the same problem, since they have the same dependency. Basically, it would be good to know what the intention of libudev actually is before making a move on this bug. But to avoid all these methods raising a KeyError, the only real option at this time is to have __getitem__() raise a KeyError when the item is not among the keys, but return None when it is among the keys but lookup fails. If that is the correct thing to do, then it is at least quite straightforward. > udev_device_get_sysattr_list_entry returns a list of attribute, value pairs. > The values are NULL, the attributes are said to be "available". It only returns a list of file names, like "ls". You cannot use the values in this list, they are not set. > but if these attributes are further looked up by > "udev_device_get_sysattr_value" they may have no value The same way as "cat" of the file name returned by "ls" may result in an error, no value, for whatever reason. "physical_node" is a pointer to a device, not an attribute, trying to read it as an attribute value returns NULL. This this the expected behavior. Note: Please be very careful by blindly reading all things available in /sys, some attributes change the behavior of the system, just by reading the values. /sys is not for poking around, without knowing what it does. Privileged programs can cause harm here, just by opening and reading random files. The other option is not to make Attributes a subclass of Mapping. That is an idea worth investigating, since the mapping is in general partial (see Comment #3). This should be deferred until 7.3. It turns out that it is more of a design flaw than a simple fix, so it will require a change in the Attributes class, rather than just a simple two line change in a single method. At the same time, it seems that users of the library are not using it in a way that triggers the bug. They are using it more like the underlying libudev library was intended to be used, apparently. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. There is still a problem, because the two methods that this class depends on don't seem to have a very easy to discover relationship. So, it seems like this Attributes class should stop having any notion of keys at all until that gets worked out. The relationship was easy to discover, but not really deep or meaningful, see related bug. This is fixed in pyudev version 0.18. I think my responsibility ends now that it is fixed upstream. The fix results in some issues with Attributes.tostring() method, so I'm reassigning. Fixed in version 0.18.1. python-pyudev-0.18.1-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-7eb77298d4 python-pyudev-0.18.1-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-7eb77298d4 Whoops, an unintended effect of filling in some bodhi field. python-pyudev-0.18.1-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report. |