Bug 1939970
| Summary: | [RFE] Sort network devices before matching by regex | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Yanir Quinn <yquinn> |
| Component: | tuned | Assignee: | Jaroslav Škarvada <jskarvad> |
| Status: | CLOSED ERRATA | QA Contact: | Robin Hack <rhack> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.3 | CC: | jeder, jskarvad, jzerdik, lnykryn, rhack |
| Target Milestone: | rc | Keywords: | FutureFeature, Patch, Triaged, Upstream |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://github.com/redhat-performance/tuned/pull/333 | ||
| Whiteboard: | |||
| Fixed In Version: | tuned-2.16.0-0.1.rc1.el8 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-11-09 19:58:24 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
Yanir Quinn
2021-03-17 11:11:23 UTC
It seems the libudev API sorts it. After bit digging into the libudev implementation, it seems the udev_device_get_properties_list_entry sorts the properties alphabetically as a side effect of usage of udev_list_entry_add which is working over unique/hashed udev_list. The 'udevadm' tool doesn't use it, so its result is not sorted. But the libudev API documentation doesn't explicitly guarantee (I wasn't able to find such text) that the list is sorted. We could explicitly sort it in the TuneD, but I don't want to add redundant code and additional overhead.
@Lukas, can we rely on the fact that the following code outputs alphabetically (ASCII) sorted list of properties?
struct udev_list_entry *list;
struct udev_list_entry *node;
list = udev_device_get_properties_list_entry (dev);
udev_list_entry_foreach (node, list) {
printf ("%s: %s\n", udev_list_entry_get_name(node), udev_list_entry_get_value(node));
}
E.g. the following sorted output:
ID_ATA: 1
ID_BUS: ata
SCSI_TYPE: disk
SUBSYSTEM: block
TAGS: :systemd:
E.g. the ID_ATA is before TAGS. Is this behavior guaranteed in RHEL-7 and newer? Or could you point us to somebody who could answer this question?
(In reply to Jaroslav Škarvada from comment #2) > It seems the libudev API sorts it. After bit digging into the libudev > implementation, it seems the udev_device_get_properties_list_entry sorts the > properties alphabetically as a side effect of usage of udev_list_entry_add > which is working over unique/hashed udev_list. The 'udevadm' tool doesn't > use it, so its result is not sorted. But the libudev API documentation > doesn't explicitly guarantee (I wasn't able to find such text) that the list > is sorted. We could explicitly sort it in the TuneD, but I don't want to add > redundant code and additional overhead. > > @Lukas, can we rely on the fact that the following code outputs > alphabetically (ASCII) sorted list of properties? > > struct udev_list_entry *list; > struct udev_list_entry *node; > > list = udev_device_get_properties_list_entry (dev); > > udev_list_entry_foreach (node, list) { > printf ("%s: %s\n", udev_list_entry_get_name(node), > udev_list_entry_get_value(node)); > } > > E.g. the following sorted output: > > ID_ATA: 1 > ID_BUS: ata > SCSI_TYPE: disk > SUBSYSTEM: block > TAGS: :systemd: > > E.g. the ID_ATA is before TAGS. Is this behavior guaranteed in RHEL-7 and > newer? Or could you point us to somebody who could answer this question? According to systemd upstream this behavior cannot be relied upon. Thanks Lukas for providing the answer (off channel). Upstream PR: https://github.com/redhat-performance/tuned/pull/333 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (tuned bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4476 |