Unify mechanism traits #162
Merged
Conversation
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
Contributor
|
I like that |
robin-nitrokey
force-pushed
the
mechanisms
branch
from
8624e88 to
32d3d9f
Compare
Member
Author
|
Rebased onto main and updated so that we now only define a single list of implemented mechanisms. |
This was referenced Mar 4, 2025
Member
Author
|
@sosthene-nitrokey @daringer Can you please review this so that we can include it in the next release? |
This patch combines the operation traits that were previously used to call mechanism implementations into a single MechanismImpl trait. This has several advantages: - We can use a macro to implement the dispatch from the Mechanism enum, removing boilerplate code from the reply_to implementation. - To implement an operation for a mechanism, it is now sufficient to override the respective trait method. It is no longer necessary to also update reply_to. - The need to annotate all mechanism methods with #[inline(never)] to avoid producing a huge reply_to function (see the comment in mechanisms.rs) is reduced as we can just mark the methods generated by the macro as #[inline(never)]. - This reduces the binary size required in the stable nitrokey-3-firmware by some kB.
This patch removes the manual mechanism enumeration in IMPLEMENTED_MECHANISMS and changes the rpc_trait! macro to also generate this constant so that it acts as a single source of truth. As a side effect, the IMPLEMENTED_MECHANISMS constant is moved from types to service and only available if the crypto-client feature is enabled.
This patch makes the mechanisms module private. The mechanism implementation can still be accessed using the Mechanism enum. This leads to a clenaer public API and triggers a compiler warning if the mapping between the Mechanism enum and the mechanism implementations is wrong (as the implementation would then be unused).
robin-nitrokey
force-pushed
the
mechanisms
branch
from
32d3d9f to
1408449
Compare
sosthene-nitrokey
approved these changes
Mar 10, 2025
Contributor
|
I don't really like Not a blocker. |
The paste dependency is unmaintained and not really necessary for our use case.
Member
Author
|
Unfortunately |
sosthene-nitrokey
approved these changes
Mar 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This patch combines the operation traits that were previously used to call mechanism implementations into a single MechanismImpl trait. This has several advantages: