| /openbmc/libpldm/src/transport/ |
| H A D | container-of.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | meson.build | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | transport.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | mctp-demux.c | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | transport.c | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| /openbmc/libpldm/src/ |
| H A D | mctp-defines.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | meson.build | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| /openbmc/libpldm/include/libpldm/transport/ |
| H A D | mctp-demux.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| /openbmc/libpldm/include/libpldm/ |
| H A D | transport.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | base.h | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| H A D | meson.build | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| /openbmc/libpldm/src/requester/ |
| H A D | pldm.c | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|
| /openbmc/libpldm/ |
| H A D | meson.build | c1b66f42 Thu Dec 08 23:24:45 CST 2022 Rashmica Gupta <rashmica@linux.ibm.com> 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
|