Lines Matching +full:implementation +full:- +full:specific
8 BMC. This is primarily IPMI-based, but also includes a few hardware-specific
9 side-channels, like hiomap. On OpenPOWER hardware at least, we've definitely
27 attempted, but not in a cross-implementation manner so far. This does not
40 
45 stack needing to be aware of the hardware implementation. These higher levels
48 that communicates over MCTP - for example, the host device, the BMC, or any
49 other system peripheral - static or hot-pluggable.
54 For example, the PLDM design at [pldm-stack.md].
58 the higher-level data transferred between MCTP endpoints, which packets are
61 packets by the transmit implementation, and reassembled at the receive
62 implementation.
68 - Have a simple serialisation and deserialisation format, to enable
72 - Allow different hardware channels, as we have a wide variety of target
75 - Be usable over simple hardware implementations, but have a facility for higher
78 - Ideally, integrate with newer messaging protocols
84 - A userspace-based approach, using a core library, plus a demultiplexing
85 daemon. This is described in [MCTP Userspace](mctp-userspace.md).
89 - A kernel-based approach, using a sockets API for client and server
91 in [MCTP Kernel](mctp-kernel.md)
99 There have been two main alternatives to an MCTP implementation in OpenBMC:
104 platform-specific customisations. This also does not solve the hardware channel
109 While this may be present in some environments (for example, UEFI-based
112 stack - indeed, MCTP has a proposal for a Redfish-over-MCTP channel (DSP0218),
119 users of the MCTP messaging (eg, a PLDM implementation). These would somewhat