Message-ID: <2023083110-delicacy-thinly-5af6@gregkh>
Date:   Thu, 31 Aug 2023 09:58:04 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Nícolas F. R. A. Prado 
        <nfraprado@...labora.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org, kernel@...labora.com
Subject: Re: Stability guarantees on uevent variables?

On Thu, Aug 24, 2023 at 07:08:39PM -0400, Nícolas F. R. A. Prado wrote:
> 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?

Only if the normal userspace tools that use those variables require it.

> 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?

No, modalias is not stable, it can change over time (add new fields), as
it is just a userspace representation of how to call 'modprobe' and
match up with the kernel-provided module alias fields.

So the value will always match the module alias fields, but userspace
shouldn't be attempting to parse the thing at all, as that makes no
sense (the kernel understands the format, userspace does not need to.)

> 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.

So you want to see if a driver is possible for this device, or if the
driver failed to bind to the device?  Those are different things.

> 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.

Yes, driver names get changed all the time, and move around the kernel
tree as well.  That's not going to stop, but it shouldn't affect
testing, right?

> 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.

Just use the symlink, that shows if a device actually has a driver bound
to it.  Note that drivers can refuse to bind to a device for loads of
reasons, even if it's probe function is properly called by the kernel.

So for regressions, just see if there is a link from all devices to a
driver and you should be fine.  No need to mess around with module
aliases at all, as you don't want to put the parsing of those structures
in userspace as well, right?

thanks,

greg k-h

Powered by blists - more mailing lists