On Tue, Jul 21, 2026 at 2:39 PM Milos Tijanic <[email protected]> wrote: > > On Wed, 2026-07-15 at 01:14 +0400, Mohamed Ahmed wrote: > > A section that has > > not been polled yet, or that the board does not support, reads > > -ENODATA. > > Per hwmon/sysfs-interface.rst: "All entries (except name) are optional, > and should only be created in a given driver if the chip has the > feature." > > It feels really weird to have a bunch of things there that just give an > error code when reading. Does anything else use this pattern? >
The power_supply sysfs group does something similar to this but this was something I was not sure how to handle and wanted more feedback on in general. I went with this with the logic that it would be similar to nvidia-smi's "N/A". The other alternative was going for something like hwmon where we detect if it's supported early on by probing everything and latching onto them and then unsupported stuff is simply dropped, but that approach felt not suitable because of the polling nature (if for some reason we couldn't latch onto something, it wouldn't show even if it were supported). Another alternative now that I think about it more is that we could block for up to 1 poll interval if we get an invalid read, which would eliminate the transient errors completely. This would leave the unsupported items and in that case we could return -EOPNOTSUPP instead which makes more sense than -ENODATA for everything. It does still have the tradeoff with missing items having error files though, so I am not sure. > > - The sysfs interface exposed here should be stable and valid for > > nova as well. > > Agreed. Please allow a bit of time for us to review the uAPI for Nova > and future GSP versions. > > > RUSD is stable and only grows more fields with newer GSP firmware > > (e.g., fan telemetry gets added in r580), so it is possible to keep > > the same interface as we use newer firmware > > Don't assume this. Work is underway to significantly rework the RUSD > layout to make it extensibe in ABI-compatible ways, but there will be > a single large ABI break compared to 570. This will happen when we add > RUSD support to Nova, so it's some months out still. > Understood, thanks! The FW ABI is fairly insulated from everything else in my design so the upcoming compatibility break shouldn't be an issue if nouveau upgrades to that firmware and the main concern is in the exposed uAPI. > > - amdgpu offers a single binary blob with all the telemetry > > embedded in > > addition to the sysfs sensor files. This series currently only > > exposes > > sensor files, but it is possible to add a similar binary for a > > v2. > > This mainly offers a more efficient way to read the telemetry as > > clients would read only a few files instead of reading all of > > them. > > IIUC the reason amdgpu does that is so you can take a self-consistent > atomic snapshot of all the telemetry readings. That's just not how RUSD > works, so we don't need/want it. > > We don't want to expose binary RUSD to userspace while it is unstable. > Once it does become stable, the way this was meant to be exposed is to > allow userspace to RO mmap the buffer and read the telemetry directly, > with no syscall overhead. But I'm kind of loathe to do that even with > the new format as it will require some parsing and that's easy to get > wrong on the userspace side and still work in a given version, then > break with an update. > > We can revisit this when ABI-stable RUSD comes, and then maybe have a > reference librusd that does the parsing. > > Noted, thanks! My original idea was 4 binaries (1 for each poll domain) but your idea is strictly better, so waiting till then and revisiting this is a better idea.
