fwmanager: Add BootControl trait and HAL adapter#355
Conversation
|
@rusty1968 @leongross Can you have a look? |
b6b55ae to
d55e95f
Compare
| /// ``` | ||
| pub trait BootControl { | ||
| /// The error type reported by this device's boot control. | ||
| type Error: core::fmt::Debug; |
There was a problem hiding this comment.
Only having Debug limits error handling downstream (in the orchestrator).
Requiring core::error::Error is more modern as it is available in core for a while now.
The openprot-hal implements its own Error trait, we might just require that or make the hal compatible with core::error::Error (so access to the ErrorKind could be acquired by downcasting).
There was a problem hiding this comment.
Thanks, very good catch!
| let err = bmc | ||
| .hold_in_reset() | ||
| .expect_err("expected the controller error to propagate"); | ||
| assert_eq!(err.kind(), ErrorKind::InvalidResetId); |
There was a problem hiding this comment.
If the bmc is a generic BootControl calling err.kind() won't work.
See the other comment about improving the BootControl::Error.
If we change BootControl to provide better means to access the error details add a test or change this test to validate it.
There was a problem hiding this comment.
Good point! BootControl::Error now requires core::error::Error + system_control::Error, so a generic consumer can call err.kind() for categorization and gets Display/source() from core::error::Error. I also added compile and runtime checks. Does the current iteration make sense to you?
Introduce the Boot Orchestrator's actuation capability: the BootControl trait (hold_in_reset / release) and HalBootControl, which binds one HAL ResetControl line to a managed device. Includes a host unit test verifying that holding a device in reset asserts exactly its configured line. Includes tests that release deasserts the device's configured line and that a controller error surfaces through BootControl unchanged. Extend the fake reset controller with opt-in failure injection to drive the error case. Closes: #2 Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Christina Quast <christina.quast@9elements.com>
Co-authored-by: Marvin Gudel <marvin@gudel.org>
e10f4c6 to
daa9aa7
Compare
Tighten BootControl::Error from Debug-only to `core::error::Error + system_control::Error` so the orchestrator gets Display and a source() cause chain instead of just the Debug dump, and so generic `BootControl` consumers can categorize failures via kind() without downcasting to a concrete error type. HAL reset controllers keep the existing Error/kind() pattern unchanged; the new BootError adapter supplies the core::error::Error machinery over any HAL error, so no per-implementation work is required. Cover the combined bound with a compile-time fence and tests for Display output, source(), dyn downcast, and kind() reached through a generic BootControl. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Christina Quast <christina.quast@9elements.com>
2 participants
Introduce the Boot Orchestrator's actuation capability: the BootControl trait (hold_in_reset / release) and HalBootControl, which binds one HAL ResetControl line to a managed device. Includes a host unit test verifying that holding a device in reset asserts exactly its configured line.
Includes tests that release deasserts the device's configured line and that a controller error surfaces through BootControl unchanged. Extend the fake reset controller with opt-in failure injection to drive the error case.
Closes: 9elements#2
Assisted-by: Claude:claude-opus-4-8