libpldmresponder comments

[Deepak Kodihalli]

On 04/10/19 7:26 PM, Supreeth Venkatesh wrote:
> Hello Deepak/all,
> 
> Sorry for the late comments/feedback.

No problem, thanks for the feedback Supreeth!

> I was looking at porting libpldmresponder and libpldm to an Arm based 
> platform.

libpldm - sure, it is meant to be portable across OpenBMC, but 
libpldmresponder is not :)

> These are  few observations with the design, some of them were discussed 
> during OSF OpenBMC Hackathon, summarizing them here:
> 
> Assumption was that libpldmresponder can be easily ported to Host/other 
> Satellite/Service Management controller,

libpldmresponder was not meant to be ported outside OpenBMC - it's the 
OpenBMC implementation of the BMC as a PLDM responder.

> However, in the current design,
> 
>  1. libpldmresponder implements standard Commands/APIs defined by PLDM
>     specifications in C++.
>  2. libpldmresponder PDR, BIOS config structures are defined by PLDM
>     specifications, However, the library uses Json format, thus making
>     JSON parser mandatory for 
> Host/Service management controller firmware.
> 
>  3. libpldmresponder has DBUS/other OpenBMC implementation dependencies,
>     thus making portability harder. >  4. I guess the expectation when we started with the design was that
>     there will be one **single** library which will handle all pldm
>     requests/responses and 
> 
> upper layer application/Daemon will call the APIs provided by PLDM 
> library to implement use cases as they fit.

https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md makes 
the distinction between a portable libpldm (which handles the protocol 
encode/decode), and an OpenBMC specific responder implementation.

>  5. Libpldm also has dependencies on OpenBMC structures/DBUS objects,
>     making it a little harder to port.

No, libpldm has no OpenBMC dependencies. It for example is used by IBM's 
host firmware stacks today without any code changes. Can you point me to 
where you see D-Bus dependencies in libpldm? Do you just mean you find 
this hard to build outside an OpenBMC environment?

> Please let me know, how I can help fix some of these, so that it is 
> easily portable.

No change should be needed to libpldm code, it should already be 
portable like noted earlier. As far as the libpldmresponder is 
considered, like we discussed at the OSFC, one thing we could do is to 
write a responder API layer, the implementation of which is platform 
(for eg OpenBMC/ARM) specific. Would you like to propose a design update 
for this to the existing document? I think we need to understand the 
usefulness of such a layer though. I mean for example if you consider a 
PLDM command along the lines of ReadSensor, such a sensor maybe a D-Bus 
object on OpenBMC and something else on the ARM platform, those 
specifics *must* be implemented on the platform, so what would the 
portable layer consist of? Those details would be good to capture in the 
design doc.

> Thanks,
> 
> Supreeth
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy 
> the information in any medium. Thank you.