-
Notifications
You must be signed in to change notification settings - Fork 50
Add relayable service event plumbing #866
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -116,6 +116,9 @@ pub mod mctp { | |
|
|
||
| /// The result type that this service handler processes | ||
| type ResultType: super::SerializableResult; | ||
|
|
||
| /// The event type that this service emits. | ||
| type EventType; | ||
| } | ||
|
|
||
| /// Trait for a service that can be relayed over an external bus (e.g. battery service, thermal service, time-alarm service) | ||
|
|
@@ -448,6 +451,14 @@ pub mod mctp { | |
| } | ||
|
|
||
|
|
||
| /// A common event type wrapper for all relayable service events. | ||
| #[derive(Debug)] | ||
| pub enum ServiceEvent { | ||
| $( | ||
| $service_name(<$service_handler_type as $crate::relay::mctp::RelayServiceHandlerTypes>::EventType), | ||
| )+ | ||
| } | ||
|
|
||
| pub struct $relay_type_name { | ||
| $( | ||
| [<$service_name:snake _handler>]: $service_handler_type, | ||
|
|
@@ -466,6 +477,33 @@ pub mod mctp { | |
| )+ | ||
| } | ||
| } | ||
|
|
||
| /// Build an event multiplexer from the provided relayable services. | ||
| /// | ||
| /// This is generic over the receiver type used for each service, so callers | ||
| /// can decide at the call site which concrete `Receiver<EventType>` impl to | ||
| /// supply for each relayed service (e.g. `NeverReceiver`, an embassy channel | ||
| /// `Receiver`, a `DynamicReceiver`, or a custom impl). | ||
| /// | ||
| /// The caller will then need to further filter this event mux to whatever | ||
| /// events they consider worth notifying the host about. | ||
| /// | ||
| /// Lastly, the caller will then need to map the events into a format the | ||
| /// relay service understands (e.g. a single u8 for uart-service). | ||
| pub fn event_mux< | ||
| $( | ||
| [<$service_name Rx>]: $crate::event::Receiver< | ||
| <$service_handler_type as $crate::relay::mctp::RelayServiceHandlerTypes>::EventType | ||
| >, | ||
| )+ | ||
| >( | ||
| $( | ||
| [<$service_name:snake _event_rx>]: [<$service_name Rx>], | ||
| )+ | ||
| ) -> impl $crate::event::Receiver<ServiceEvent> { | ||
| $crate::event::MuxReceiver::new() | ||
| $(.with([<$service_name:snake _event_rx>], ServiceEvent::$service_name))+ | ||
| } | ||
| } | ||
|
|
||
| impl $crate::relay::mctp::RelayHandler for $relay_type_name { | ||
|
|
@@ -494,6 +532,7 @@ pub mod mctp { | |
|
|
||
| // Allows this generated relay type to be publicly re-exported | ||
| pub use [< _odp_impl_ $relay_type_name:snake >]::$relay_type_name; | ||
| pub use [< _odp_impl_ $relay_type_name:snake >]::ServiceEvent; | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hm, though with the current approach: the caller has to filter and map the MUXed event receiver, the caller needs to know about the ServiceEvent type no? |
||
|
|
||
| } // end paste! | ||
| }; // end macro arm | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think all this filtering stuff belongs in the relay handlers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought about that, but I was trying to maximize flexibility in that I'm not sure if we should assume that all users will agree on what events are considered "notifiable". Maybe some users have platforms where they want to notify the host in case of sensor error where others don't.