Keyvault interop #64
Closed
Keyvault interop #64
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
… layering Introduces a comprehensive I2C hardware abstraction layer with composable traits organized by execution semantics, and establishes clear separation between hardware abstraction and application device layers. New I2C Hardware Abstractions: - `I2cHardwareCore`: Foundation trait with basic I2C controller operations - `I2cMaster`: Master mode operations (write, read, transactions) - `I2cSlaveCore`: Basic slave address configuration and mode control - `I2cSlaveBuffer`: Slave data transfer operations - `I2cSlaveInterrupts`: Common interrupt and status management - `I2cSlaveEventSync`: Blocking slave event handling (in hal-blocking) - `I2cSlaveEventPolling`: Non-blocking slave event handling (in hal-nb) - Composite traits: `I2cSlaveBasic`, `I2cSlaveSync`, `I2cSlaveNonBlocking` Layer Separation and Clarification: - Rename `i2c_target.rs` → `i2c_device.rs` to clarify purpose - Establish distinction between layers: - `i2c_hardware.rs`: Hardware abstraction (controllers, buses, interrupts) - `i2c_device.rs`: Application layer (sensors, EEPROMs, device behaviors) - Add comprehensive documentation explaining layer boundaries - Hardware traits use associated types for configuration - Device traits focus on application-specific behaviors Architecture Decisions: - Clean separation: blocking operations in `hal-blocking`, non-blocking in `hal-nb` - Composable design: small focused traits that can be combined as needed - Associated types for hardware-specific configuration and errors - Integration with embedded-hal 1.0 error types Benefits: - Clear separation between hardware abstraction and application layers - Hardware drivers can implement only needed capabilities - Clear execution semantics (blocking vs non-blocking) - Extensible without breaking existing code - Supports diverse I2C hardware implementations - Compatible with both interrupt-driven and polling architectures
…e traits. - Configurable success/failure behavior for testing error paths - Event injection system for simulating slave events - Data injection for testing slave receive scenarios - Buffer management with realistic size constraints - State tracking for all operations
- Add init_with_clock_control() and configure_timing_with_clock_control() methods to I2cHardwareCore - Implement clock control methods in MockI2cHardware with comprehensive documentation - Fix doctest compilation errors by converting examples to text blocks - Add ClockControl and ErrorType trait integration for advanced timing configuration - Create architectural documentation for I2C subsystem design patterns
integration - Add SystemControl trait combining ClockControl + ResetControl - Update I2C hardware traits to use SystemControl instead of ClockControl - Rename init_with_clock_control to init_with_system_control - Rename configure_timing_with_clock_control to configure_timing_with_system_control - Update mock implementation to match new trait signatures - Improve documentation with reset management examples
Add comprehensive SystemControl integration pattern for I2C hardware initialization and timing configuration. This demonstrates how external system controllers can manage peripheral clocks and resets during I2C setup. Changes: - Add MockSystemControl implementation with clock and reset control - Add MockI2cHardwareWithSystem showing dependency injection pattern - Remove closure-based SystemControl methods from I2C HAL trait - Add comprehensive test suite (31 tests) covering integration patterns - Clean up clippy warnings and improve error handling The new pattern uses composition over complex trait methods, providing clearer separation of concerns between system-level operations (clock/reset) and peripheral-specific operations (I2C timing).
- Add KeyStore, KeyLifecycle, and KeyLocking traits for key management - Implement generate_and_store_keypair function for ECDSA-vault integration - Add compute_mac_with_vault function for MAC-vault integration - Fix PrivateKey trait to use curve parameter in validate method - Export key_vault module in HAL public API Enables secure key storage integration across cryptographic modules while maintaining existing HAL design patterns.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Introduce KeyVault abstractions and generic interoperability functions.
Interoperability functions
Fixed :