| commit | 1a4ec3cd81a8c8c5c458beda0f5ace186c5b37e9 | [log] [tgz] |
|---|---|---|
| author | Jeremy Kerr <jk@ozlabs.org> | Tue Sep 03 11:01:50 2019 +0800 |
| committer | Jeremy Kerr <jk@ozlabs.org> | Wed Nov 27 11:35:28 2019 +0800 |
| tree | 4be3bb4976c954c2c5eeb08018b75d46d31887b2 | |
| parent | 80971f843485133e8953874341522111f08ea8b5 [diff] |
core,API: Add bridge support This change introduces a facility to bridge messages between two bindings. This is implemented through a new mctp_bridge_busses() API, which applies a new routing policy, sending packets from one binding to the other. This is in contrast to the current policy of dropping all non-local packets. To do this, the message context code needs to know both source and destination EIDs, so add them to the mctp_msg_ctx_lookup() criteria. Also, add a small test for bridge mode. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Change-Id: If532613525ddbf81df249e26d0f23825996f7bda
This library is intended to be a portable implementation of the Management Component Transport Protocol (MCTP), as defined by DMTF standard "DSP0236", plus transport binding specifications.
Currently, the library is is only at prototyping stage. Interfaces will likely change, and are missing lots of components of the standard.
To initialise the MCTP stack with a single hardware bus:
mctp = mctp_init(): Initialise the MCTP corebinding = mctp_<binding>_init(): Initialise a hardware bindingmctp_register_bus(mctp, binding, eid): Register the hardware binding with the core, using a predefined EIDThen, register a function call to be invoked when a message is received:
mctp_set_rx_all(mctp, function): Provide a callback to be invoked when a MCTP message is receivedOr transmit a message:
mctp_message_tx(mctp, message, len): Transmit a MCTP messageThe binding may require you to notify it to receive packets. For example, for the serial binding, the mctp_serial_read() function should be invoked when the file-descriptor for the serial device has data available.
libmctp implements basic support for bridging between two hardware bindings. In this mode, bindings may have different MTUs, so packets are reassembled into their messages, then the messages are re-packetised for the outgoing binding.
For bridging between two endpoints, use the mctp_bridge_busses() function:
mctp = mctp_init(): Initialise the MCTP coreb1 = mctp_<binding>_init(); b2 = mctp_<binding>_init(): Initialise two hardware bindingsmctp_bridge_busses(mctp, b1, b2): Setup bridgeNote that no EIDs are defined here; the bridge does not deliver any messages to a local rx callback, and messages are bridged as-is.
The libmctp code is intended to be integrated into other codebases by two methods:
as a simple library (libmctp.{a,so}) which can be compiled separately and linked into the containing project
as a set of sources to be included into the containing project (either imported, or as a git subtree/submodule)
For (1), you can use the top-level makefile to produce libmtcp.a.
For (2), the Makefile.inc file provides the minimum set of dependencies to either build libmctp.a, or just the actual object files (LIBMCTP_OBS), which you can include into your existing make definitions. You'll want to set LIBMTCP_DIR to refer to the subdirectory that contains that makefile, so we can set the correct paths to sources.
This library is intended to be portable to be used in a range of environments, but the main targets are:
For the latter, we need to support customisation of the functions that libmctp uses (for example, POSIX file IO is not available).
In order to support these, we have a few compile-time definitions:
MCTP_HAVE_FILEIO: define if POSIX file io is available, allowing the serial hardware binding to access char devices for IO.
MCTP_HAVE_SYSLOG: allow logging to syslog, through the vsyslog call.
MCTP_DEFAULT_ALLOC: set default allocator functions (malloc, free, realloc), so that applications do not have to provide their own.