TL;DR This effectively reverts8327fd1b11,eaba9bb3e6, and its follow-ups, as the original issue was already fixed by the kernel side. The original issue that the above commits tried to 'fix' is that reading phys_port_name triggers a lock in the kernel, hence processing multiple interfaces at the same time causes extreme slow down. To workaround the issue, the above commits made several necessary information retrieved through netlink instead of sysfs attributes. A patch set for the kernel was proposed as a fix for the issue: https://lore.kernel.org/all/20210928125500.167943-1-atenart@kernel.org/ and some of them were merged to v5.16:146e5e7333, It has been already backported to 5.4.160, 5.10.80, 5.14.19, and 5.15.3. When these commits were proposed, it is already claimed that such issue should be fixed by the kernel side, and udevd should not workaround it. Neverthless the feature was introduced, as these have theoretical performance improvement, even if phys_port_name sysattr does not have the above issue, as in that way udevd can obtain multiple information about the interface with a single netlink socket operation. See the discussion in #20744. However, in reality, only `iflink`, `type`, `address`, and `phys_port_name` attributes from netlink are used in the udev net_id builtin command. Hence, after the original issue being fixed in the kernel side, there should be almost no performance improvement for udevd. Furthermore, combining attributes from netlink and sysfs makes hard to test net_id builtin. See #21725. Let's drop mostly meaningless code, and make net_id builtin easily testable. Closes #21725.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.
