Repository navigation
Side by side commands - #439
Merged
Merged
Conversation
The gpio modules map the GPIO registers with go-rpio before every operation and unmap them after it. go-rpio keeps that mapping in package variables, so it is shared by the whole agent. Two operations at once, such as GPIO commands on two devices, could unmap the registers while the other one still wrote them. Go cannot recover from that fault, so it ended the agent and every command on every device. Operations now take a lock around map, operation and unmap. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
A run, reservation or lock refused because another user's command runs on the device reported 'device "dev" is locked by "bob"'. Nobody locked it: the device is busy with bob's command, and dutctl list already shows it as in use. The refusal now reads 'device "dev" is in use by "bob"'. A refusal because of another user's reservation keeps its text. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
A run's busy hold was released by device and owner name. That is safe only while a device runs one command at a time: as soon as two runs of one user share a device, the first to end would free it under the other, and a late release of an old run would end the hold of a newer one. AutoLock now takes the command's name and returns a Lease, and only that Lease's Release ends the hold. The locker keeps one lease per running command, so a release can only ever remove its own lease, and releasing twice does nothing. ClearAutoLock is gone, and with it the warning about a missing hold, which can no longer happen. A device still runs one command at a time; no behaviour changes. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
A device ran one command at a time, even for its owner. With an interactive console open, a user could not power-cycle the device from a second terminal, and a console cannot be folded into one command with the power cycle once a person types into it. A user's different commands now run on a device at once, each holding it through a lease of its own, so the device stays busy until the last of them has returned. Two things stay refused: another user's command, and the same command twice at once, by device and command name whatever its arguments. A command's runs share its module instances, and some modules keep per-run state in them: flash stores the operation in Run and reads it back later, so a read beside a write of the same command could run as a write. The refusal names the command: device "dev" is already running "flash" for "alice@lab"; a command does not run twice at once, and a cancelled one keeps running until it has stopped What the commands do to the device together is up to the user, and hardware that two commands share is up to the admin, as it was for two commands on one GPIO pin; the agent does not check it. The new docs/device-access.md states what dutagent takes care of and what is up to users and admins. The dutctl usage text, the module contract, the module guide, the serial module's README, the shutdown description and a firmware CI comment say the same. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
…side The new record explains why a user's different commands may now run on a device at once while the same command never runs twice, why that needs no opt-in, and why shared hardware stays the admin's responsibility. It supersedes the record that made a device run one command at a time, which now names its successor. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
A new stage opens the interactive console and, while it is open, runs a second command of the same user on the device, as a power cycle from a second terminal would. That command must run, a second start of the console must be refused with the message that names it, and the console must still end normally. Every call passes the same user with -u, since without $USER each call would count as a user of its own. Signed-off-by: Jens Topp <jens.topp@blindspot.software>
jenstopp
force-pushed
the
feat/side-by-side-commands
branch
from
November 5, 2026 14:44
edfb3ca to
a803826
Compare
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.
A device ran one command at a time, even for its owner, so a user with
serial -iopen could not power-cycle the DUT from a second terminal. Now a user's different commands run side by side; another user's command and the same command twice stay refused. Each run holds the device through a lease of its own, so the device stays busy until the last run has returned. Protocol and client are unchanged.What dutagent enforces and what is up to users and admins is in the new
docs/device-access.md; the decision is ADR-0036, which supersedes ADR-0030. Details are in the commit messages.Step towards #415.