| commit | c1b66f420912dd659a4159ebd176af18347958f4 | [log] [tgz] |
|---|---|---|
| author | Rashmica Gupta <rashmica@linux.ibm.com> | Fri Dec 09 16:24:45 2022 +1100 |
| committer | Andrew Jeffery <andrew@aj.id.au> | Fri Apr 21 04:11:06 2023 +0000 |
| tree | 988d468483dd2b0d50f7ae49742298d244ac0a74 | |
| parent | 36af84cdbb660953d73804a12dfda056c3ac9b08 [diff] |
requester: Add new APIs to support multiple transports This patch has two goals: (1) enable consumers to send PLDM messages over different transports and (2) do this in a way that allows us to move towards a cleaner and more complete set of requester APIs. The sole transport option of MCTP via the userspace mctp-demux-daemon is being deprecated. New transports are being added: MCTP via the kernel (AF_MCTP) and eventually NC-SI. As such, the requester APIs need updating to support multiple transports, as well as not having MCTP specific details in the APIs. To avoid a flag day, the current APIs (pldm_send, etc) have been rewritten terms of the new APIs. The current APIs operate at the transport level - they don't implement all of the behaviour necessary for a requester. As such, the new APIs to send/recv a message have the prefix `pldm_transport`, rather than `pldm_requester`. Given the level that these APIs are operating at, these only send and receive a PLDM message. Any additional logic, such as looking for a response with a particular instance ID, belongs at the requester abstraction level. Some of the missing behaviours to fully be a PLDM requester are: assigning instance IDs, request retransmission, implementing timeouts, and enforcing only one PLDM request to a specific TID at a time. These things are currently implemented in pldmd, meaning any consumer other than pldmd using the libpldm "requester" APIs doesn't get the full functionality of a requester and has to implement these things themselves. We would like to eventually move these behaviours into libpldm so the libpldm requester APIs actually implement what is required to be a PLDM requester. The next steps to add in a full set of requester APIs, while enabling the use of multiple transports looks something like this: 1) add instance id APIs into libpldm. 2) convert pldmd to use libpldm instance id APIs - so all users of PLDM are still using the same instance id allocation method. 3) convert all consumers of libpldm over to using the new libpldm APIs, including the instance id functions. 4) add in the AF_MCTP transport and move consumers over to it. 5) refactor the encode/decode functions to only encode/decode and not frame the message (ie, remove the instance id from these functions) 6) add additional requester functionality into libpldm, and have these use the `pldm_transport` APIs directly. 7) move consumers over to the new `pldm_requester` APIs. 8) remove unused code from pldmd. Signed-off-by: Rashmica Gupta <rashmica@linux.ibm.com> Change-Id: I06e602831f360bbd0efda53d410bfb5080b3100d
This is a library which deals with the encoding and decoding of PLDM messages. It should be possible to use this library by projects other than OpenBMC, and hence certain constraints apply to it:
Source files are named according to the PLDM Type, for eg base.[h/c], fru.[h/c], etc.
Given a PLDM command "foo", the library will provide the following API: For the Requester function:
encode_foo_req() - encode a foo request decode_foo_resp() - decode a response to foo
For the Responder function:
decode_foo_req() - decode a foo request encode_foo_resp() - encode a response to foo
The library also provides API to pack and unpack PLDM headers.
Need meson and ninja. Alternatively, source an OpenBMC ARM/x86 SDK.
meson setup builddir && ninja -C builddir
The simplest way of running the tests is as described by the meson man page:
meson setup builddir && meson test -C builddir
This will support OEM or vendor-specific functions and semantic information. Following directory structure has to be used:
libpldm |---- include/libpldm | |---- oem/<oem_name>/libpldm | |----<oem based .h files> |---- src | |---- oem/<oem_name> | |----<oem based .c files> |---- tests | |---- oem/<oem_name> | |----<oem based test files>
<oem_name> - This folder must be created with the name of the OEM/vendor in lower case.
Header files & source files having the oem functionality for the libpldm library should be placed under the respective folder hierarchy as mentioned in the above figure. They must be adhering to the rules mentioned under the libpldm section above.
Once the above is done a meson option has to be created in libpldm/meson_options.txt with its mapped compiler flag to enable conditional compilation.
For consistency would recommend using "oem-<oem_name>".
The libpldm/meson.build and the corresponding source file(s) will need to incorporate the logic of adding its mapped compiler flag to allow conditional compilation of the code.
The pldm requester API's are present in src/requester folder and they are intended to provide API's to interact with the desired underlying transport layer to send/receive pldm messages.
NOTE : In the current state, the requester API's in the repository only works with specific transport mechanism & these are going to change in future & probably aren't appropriate to be writing code against.