staslib: let stacd work out what it was managing instead of remembering - #512
Merged
martin-belanger merged 1 commit intoSep 1, 2026
Merged
Conversation
stacd wrote the TIDs of the I/O controllers it managed to a pickle in $RUNTIME_DIRECTORY and, on startup, re-created a controller for each one that still had a connection in the kernel. That intersection is the tell: the kernel already knew what was connected, and the pickle only narrowed it to what had been ours. The registry answers that question now - libnvme records owner=stas on the controllers it connects for us, and claim() marks the ones we borrow - so nothing is left for stacd to remember. Ask the kernel what is connected and the registry who owns each one. This is more robust than the file it replaces: it survives a stacd that was killed before it could write, and it cannot go stale, because the registry entry is keyed by device and goes away with it. Adoption requires an entry naming us, rather than merely one not naming somebody else. protected() lets an unowned connection through on purpose - nobody has claimed it, so we may - but that is the wrong default here. Starting with no memory of what we were doing, an unowned connection is one we did not make: it predates the registry, or belongs to somebody who never registered it. stafd keeps its own file. It holds the cached discovery log pages and each controller's origin, neither of which the registry can supply, so the pickle machinery moves from ServiceABC down into Staf. stacd no longer writes to $RUNTIME_DIRECTORY at all, so its unit file no longer asks for one. Udev.get_tid() comes back, unchanged, from 27705e8 where it was dropped for want of callers. Signed-off-by: Martin Belanger <martin.belanger@dell.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #512 +/- ##
==========================================
+ Coverage 68.71% 68.93% +0.21%
==========================================
Files 16 16
Lines 2730 2739 +9
==========================================
+ Hits 1876 1888 +12
+ Misses 854 851 -3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
stacd wrote the TIDs of the I/O controllers it managed to a pickle in $RUNTIME_DIRECTORY and, on startup, re-created a controller for each one that still had a connection in the kernel. That intersection is the tell: the kernel already knew what was connected, and the pickle only narrowed it to what had been ours. The registry answers that question now - libnvme records owner=stas on the controllers it connects for us, and claim() marks the ones we borrow - so nothing is left for stacd to remember.
Ask the kernel what is connected and the registry who owns each one. This is more robust than the file it replaces: it survives a stacd that was killed before it could write, and it cannot go stale, because the registry entry is keyed by device and goes away with it.
Adoption requires an entry naming us, rather than merely one not naming somebody else. protected() lets an unowned connection through on purpose - nobody has claimed it, so we may - but that is the wrong default here. Starting with no memory of what we were doing, an unowned connection is one we did not make: it predates the registry, or belongs to somebody who never registered it.
stafd keeps its own file. It holds the cached discovery log pages and each controller's origin, neither of which the registry can supply, so the pickle machinery moves from ServiceABC down into Staf. stacd no longer writes to $RUNTIME_DIRECTORY at all, so its unit file no longer asks for one.
Udev.get_tid() comes back, unchanged, from 27705e8 where it was dropped for want of callers.