postcard serialization is only used internally and therefore is an
implementation detail that should not be part of the public API. Crates
that also need postcard serialization should declare their own
dependency for that.
This patch adds API extensions to Trussed. To avoid having to add a
type parameter to Request and Reply, we serialize the requests and
replies. Extensions can be implemented by custom backends and are
executed by the dispatch implementation provided to the Service. An
additional type parameter is needed for ClientImplementation to express
the supported extensions. See tests/ext.rs for an example
implementation.
The serialization and deserialization of the requests and replies of
course adds additional overhead. An alternative would be to make
Request and Reply generic over the set of extensions.
clippy currently complains about missing safety docs. This is not
trivial to fix because documentation is still sparse within Trussed, but
we want to ignore this for the time being to be able to use clippy in
the CI.
* All of `trussed` relies on certain facilities implemented by
a "board". These are not tightly tied to "Solo Bee", so we move
them into a crate that `trussed` itself depends on.
* The existing boards then implement this instead
* Preparing for addition of UI resources to the trussed service
(buttons, LEDs), we model a "Board" trait that on the one hand
gives access to the resources trussed needs, but on the other
hand (like the approach in littlefs/Store) is *not* generic, but
instead uses associated types. This is to prevent "generics
explosion" in the code base
Robin Krahl
Sosthène Guédon
Nicolas Stalder
Conor Patrick