Skip to content

Reserved keyword registry#333

Open
RiSKeD wants to merge 4 commits into
mainfrom
feat/reserved-keyword-registry
Open

Reserved keyword registry#333
RiSKeD wants to merge 4 commits into
mainfrom
feat/reserved-keyword-registry

Conversation

@RiSKeD
Copy link
Copy Markdown
Contributor

@RiSKeD RiSKeD commented May 13, 2026

resolves #84

RiSKeD added 4 commits May 13, 2026 10:44
CommandKeywords and DeviceKeywords list names that dutctl reserves for
client-side use ("help" for both, with room for future additions). The
registry is the single source of truth so dutctl and dutagent config
validation cannot drift as more keywords are added.

ErrReservedName lets dutagent return a typed sentinel when a config
tries to name a device or command with a reserved keyword.

Signed-off-by: Fabian Wienand <fabian.wienand@blindspot.software>
When loading the YAML config the dutagent now refuses any device or
command whose name appears in dut.DeviceKeywords or dut.CommandKeywords
respectively, returning dut.ErrReservedName via the existing
ConfigError wrapper.

Signed-off-by: Fabian Wienand <fabian.wienand@blindspot.software>
Replace the hard-coded `cmdArgs[0] == "help"` branch with a lookup
into a local handler map keyed by dut.CommandKeywords / DeviceKeywords.
An init() check guarantees every name in the registry has a handler,
so adding a future keyword is one entry in pkg/dut/reserved.go and
one in the dutctl handler map.

`dutctl help` now prints the program usage instead of attempting to
list commands for a "help" device.

Signed-off-by: Fabian Wienand <fabian.wienand@blindspot.software>
Modules must not be configured with a reserved keyword name and must
not expect one as the first argument to Run. Point readers at
dut.CommandKeywords and dut.DeviceKeywords for the authoritative list.

Signed-off-by: Fabian Wienand <fabian.wienand@blindspot.software>
@RiSKeD
Copy link
Copy Markdown
Contributor Author

RiSKeD commented May 13, 2026

Only thing i am not sure about or happy with is that we need to expose the global keywords and their handlers as global vars. Another approach would be to hide these behind functions, which in my opinion is even more cumbersome though...

@RiSKeD RiSKeD requested a review from jenstopp May 13, 2026 08:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Handle reserved keywords

1 participant