designs/mctp/mctp-userspace.md

45 The lower interface would be plugged in to one of a number of hardware-specific
46 binding implementations. Most of these would be included in the library source
47 tree, but others can be plugged-in too, perhaps where the physical layer
50 The reason for a library is to allow the same MCTP implementation to be used in
51 both OpenBMC and host firmware; the library should be bidirectional. To allow
52 this, the library would be written in portable C (structured in a way that can
53 be compiled as "extern C" in C++ codebases), and be able to be configured to
54 suit those runtime environments (for example, POSIX IO may not be available on
55 all platforms; we should be able to compile the library to suit). The licence
57 may be best.
61 implementation for running on a Linux environment may be implemented through
72 allow the daemon to be decoupled from any blocking behaviour of handlers. The
74 blocked daemon, but this would be of a limited size. Handlers whose sockets
75 exceed this queue would be disconnected from the daemon.
80 socket interface could be fairly easily swapped out with a new kernel-based
83 MCTP is intended to be an optional component of OpenBMC. Platforms using OpenBMC
95 The socket type used should be `SOCK_SEQPACKET`.
98 MCTP messages should be forwarded to the client. Types must be greater than
127 possible functionality that is available over MCTP, which may be quite a
134 as a socket-based interface. However, an alternative here would be to pass MCTP
146 be run in CI on both host and BMC.