Messages in this thread | | | Date | Thu, 24 Aug 2023 19:08:39 -0400 | From | Nícolas F. R. A. Prado <> | Subject | Stability guarantees on uevent variables? |
| |
Hi,
my question boils down to the following:
Is there a stability guarantee on the format and content of the variables in uevents produced by the kernel?
I would assume so, given that uevents are explicitly produced for userspace, and users will rely on them. However, looking through the ABI documentation I could only find two instances of uevents being defined (testing/usb-uevent and testing/usb-charger-uevent) and neither mention the variables added in the KOBJ_ADD action. The document for the uevent file in sysfs, testing/sysfs-uevent, only mentions writing synthetic uevents, rather than reading existing ones. Is the documentation simply lacking or is it intentional that uevent variables aren't covered?
I'm particularly interested in the format for the MODALIAS uevent variable. My understanding is that its only use is to match against the modules' aliases in the modules.alias file. For that reason I'm wondering whether for this variable, the guarantee would only be that the format of the value will match the one in modules.alias, but the precise format is not guaranteed (for example, a new field could potentially be introduced in the future if added to both the device uevent and module's alias). However, I do see a few ABI documentation pages for the modalias file in sysfs (eg in testing/sysfs-bus-pci), which explicitly describe the format, and that's supposed to be the same as the MODALIAS uevent, so does that mean the format itself is stable?
I'll be happy to improve the ABI documentation based on the reply to these questions.
As for the full context for these questions, as part of an effort to improve the detection of regressions affecting device probe, I want to be able to check whether devices under a discoverable bus (USB, PCI) were populated and probed by a driver. We currently do this by checking against driver and device names [1], but as has been pointed out before, that's not stable ABI, and the test might break if things get renamed or moved around. So my intention is to change that check to use modaliases or other uevents to find the device in a stable way and check for the driver symlink to verify it's been probed.
[1] https://github.com/kernelci/bootrr/blob/3ae9fd5dffc667fa96012892ea08532bc6877276/boards/google%2Cspherion#L279
Thanks, Nícolas
| |