libpldm: More fixes for header use

b0c1d20a5bde ("libpldm: Fix header use") only did half the job,
addressing compilation concerns for the library itself. As it turns out
there were still plenty of

libpldm: More fixes for header use

b0c1d20a5bde ("libpldm: Fix header use") only did half the job,
addressing compilation concerns for the library itself. As it turns out
there were still plenty of places that used local includes for paths to
the public headers.

Apply the rest of the header cleanups to hopefully get us into a
consistent state.

Fixes: b0c1d20a5bde ("libpldm: Fix header use")
Change-Id: I8d4b59c9241770583abb30389452af0a32b18b99
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

libpldm: Rationalise the local and installed path of pldm.h

Since chopping libpldm out of openbmc/pldm.git there's been a symlink
from `include/libpldm/pldm.h` pointing to
`include/libpldm/requester

libpldm: Rationalise the local and installed path of pldm.h

Since chopping libpldm out of openbmc/pldm.git there's been a symlink
from `include/libpldm/pldm.h` pointing to
`include/libpldm/requester/pldm.h`. The file list contained in the
`libpldm_headers` variable defined by `include/libpldm/meson.build`
contained an entry for `requester/pldm.h`, though not the symlink found
at `include/libpldm/pldm.h`.

Prior to a7989cd65d51 ("meson: Fix for OEM header collision issue")
`install_headers(libpldm_headers, ...)` directive didn't specify
`preserve_path: true`, therefore the `requester/pldm.h` header file was
installed directly under `${INCLUDEDIR}/libpldm` as
`${INCLUDEDIR}/libpldm/pldm.h`, and no file was installed to
`${INCLUDEDIR}/libpldm/requester/pldm.h`.

All dependent applications using the declarations in `pldm.h` therefore
included the header using the directive `#include <libpldm/pldm.h>`.
However, internal to the libpldm implementation we were using the
non-symlinked path in the local tree:
`#include "libpldm/requester/pldm.h"`

With a7989cd65d51 ("meson: Fix for OEM header collision issue") we
rationalised the meson variables used to install the headers as part of
properly separating OEM headers from one-another. This lead to
specifying `preserve_path: true` for the
`install_headers(libpldm_headers, ...)` meson directive, which further
lead to the installed location of `pldm.h` changing to
`${INCLUDEDIR}/libpldm/requester/pldm.h`. This broke all consuming
applications which were necessarily using `#include <libpldm/pldm.h>` as
outlined above.

Get rid of the symlink at `include/libpldm/pldm.h`, move
`include/libpldm/requester/pldm.h` there instead, and fix up all
internal references to the header. This unbreaks applications consuming
libpldm, and prevents internal inconsistencies going forward.

Fixes: a7989cd65d51 ("meson: Fix for OEM header collision issue")
Change-Id: I24f1e25303890c41fd3da6323c67d838022cc55d
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>

show more ...

license: add spdx identifier to all files

Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Change-Id: Ifddd07cc0eb5edeb2dcb410747073d68c6631cb1

transport: Generalise the pldm_transport_recv_msg() API

Currently pldm_transport_recv_msg() only works for requesters as the TID
param is an input. Responders need the source TID of the message
rece

transport: Generalise the pldm_transport_recv_msg() API

Currently pldm_transport_recv_msg() only works for requesters as the TID
param is an input. Responders need the source TID of the message
received so they know where to send the response.

The TID was being used to look up the EID mapped to the TID and failing
the function call if it didn't match. This check doesn't need to happen
at this level, and can be added in at the requester API level if
required.

Make the TID param an output, and use the EID of the message to lookup
the TID.

Change-Id: I671dbfe2d94a9ad8d77ea0ef150f1c744f928c53
Signed-off-by: Rashmica Gupta <rashmica@linux.ibm.com>

show more ...

transport: Fix doxygen and variables for send and recv functions

This was missed updated properly when making the transport functions
work for both requesters and responders.

Fixes: c1b66f420912 ("

transport: Fix doxygen and variables for send and recv functions

This was missed updated properly when making the transport functions
work for both requesters and responders.

Fixes: c1b66f420912 ("requester: Add new APIs to support multiple transports")
Signed-off-by: Rashmica Gupta <rashmica@linux.ibm.com>
Change-Id: Ie32f11a98ab1b11caaafbca5e837e1eda5c9cc37

show more ...

transport: Update internal header file

Rename the header guard to be in-line with other internal headers and
less likely to conflict with other headers. Also remove the c++ guard as
we don't need it

transport: Update internal header file

Rename the header guard to be in-line with other internal headers and
less likely to conflict with other headers. Also remove the c++ guard as
we don't need it in an internal header.

Signed-off-by: Rashmica Gupta <rashmica@linux.ibm.com>
Change-Id: I86ef4d478fca62a5532fbc440216e0898a463821

show more ...

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

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

show more ...