designs/mctp/mctp-userspace.md

6 description, background and requirements.
20 provides a socket-based interface for other processes to send and receive
24 handling local MCTP-stack configuration, like local EID assignments.
30 2.  one or more binding implementations (eg, MCTP-over-serial), which interact
33 3.  an interface to handler applications over a unix-domain socket.
38 - an "upper" messaging transmit/receive interface, for tx/rx of a full message
41 - a "lower" hardware binding for transmit/receive of individual packets,
45 The lower interface would be plugged in to one of a number of hardware-specific
47 tree, but others can be plugged-in too, perhaps where the physical layer
48 implementation does not make sense to include in the platform-agnostic library.
56 for the library should also allow this re-use; a dual Apache & GPLv2+ licence
60 transferring packets to the physical layer. For example, a serial binding
62 read()/write() syscalls to a PTY device. An I2C binding for use in low-level
66 The application-specific handlers implement the actual functionality provided
71 The daemon's sockets to these handlers is configured for non-blocking IO, to
77 One design intention of the multiplexer daemon is to allow a future kernel-based
79 applications. The socket-based interface facilitates this, as the unix-domain
80 socket interface could be fairly easily swapped out with a new kernel-based
88 MCTP handlers (ie, clients of the demultiplexer) connect using a unix-domain
92 \0mctp-demux
125 for passing messages from the core code to application-level handlers. The
129 implementation of those application-level handlers (programming language,
130 frameworks used, etc). Also, this single-process approach would likely need more
134 as a socket-based interface. However, an alternative here would be to pass MCTP
136 dbus is that the former allows a direct transition to a kernel-based socket API
145 For MCTP hardware bindings, we would develop channel-specific tests that would