Skip to content

Commit 9a6b837

Browse files
committed
mctp: Update README for trait changes
Signed-off-by: Matt Johnston <[email protected]>
1 parent 3aae1d1 commit 9a6b837

File tree

1 file changed

+12
-12
lines changed

1 file changed

+12
-12
lines changed

mctp/README.md

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -4,29 +4,29 @@ Management Component Transport Protocol (MCTP) support
44
This crate provides a set of generic types and traits for MCTP support in Rust.
55
It provides:
66

7-
* a few base types (`Eid`, `Tag`, `MsgType`) to match MCTP protocol
8-
definitions,
7+
* A few base types (`Eid`, `Tag`, `MsgType`, `MsgIC`) to match MCTP protocol
8+
definitions.
99

10-
* `Comm` and `Listener` traits, to abstract communication implementation details; and
10+
* Traits to abstract communication implementation details. These are
11+
`ReqChannel`, `Listener`, and `RespChannel`. Async equivalents are
12+
`AsyncReqChannel`, `AsyncListener`, and `AsyncRespChannel`.
1113

12-
* some support types (`MctpError`, `Result`) for the traits.
14+
* Some support types (`mctp::Error`, `mctp::Result`) for the traits.
1315

1416
There are two typical interfaces to the crate:
1517

16-
* Transport implementations: code that provides implementations of the `Comm`
17-
and `Listner` traits. These interface to hardware (either directly, in
18+
* Transport implementations: code that provides implementations of the traits.
19+
These interface to hardware (either directly, in some
1820
embedded environments, or through an operating system interface), and
19-
provide the base message send/receive functions
21+
provide the base message send/receive functions.
2022

21-
* Application implementations: code that uses makes use of the `Comm` trait,
23+
* Application implementations: code that uses makes use of the traits,
2224
in order to provide some MCTP-based functionality.
2325

2426
API status
2527
----------
2628

27-
While this is fairly early prototype code, there are a couple of uses "in the
28-
field" to help validate the API conventions. While we don't expect much API
29-
breakage in future, there may be reworks coming.
29+
We don't expect much API breakage in future, though changes may be made where
30+
it makes sense.
3031

3132
Any API changes will be appropriately versioned.
32-

0 commit comments

Comments
 (0)