Proposal for pldmtool

Tom Joseph tomjose at linux.vnet.ibm.com
Fri Mar 1 23:19:21 AEDT 2019



On Friday 01 March 2019 12:06 AM, Emily Shaffer wrote:
> On Wed, Feb 27, 2019 at 10:29 PM Tom Joseph <tomjose at linux.vnet.ibm.com> wrote:
>>
>>
>> On Thursday 21 February 2019 11:12 PM, Supreeth Venkatesh wrote:
>>> Tom,
>>>
>>> Thanks for sending this out as a feeler.
>>> This sounds like a logical next step after implementation of PLDM and MCTP.
>>> However, I have a couple of initial questions.
>>>
>>> " A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon."
>>> 1. Do you think it is ok to use this as external interface to BMC? I was under the impression that IPMI or Redfish were external facing interfaces to BMC.
>>>        PLDM was intended for inside the box communications.
>> I agree that PLDM is intended for inside the box communications. The
>> proposal is not to use it as an external interface, but rather give a
>> provision to run pldmtool from outside the box.
> I'm a little confused how this is different from external interface.
> Could you elaborate? Are you trying to route through the host first?

On a box shipped to customers, there would be no external interface to 
send PLDM messages to BMC. This can be considered as a debug option for 
lab purpose.

>
>>> 2. Why not use Redfish device enablement for PLDM, so that the tool (typically http/s client) will issue PLDM requests in the form of Json payload.
>> I think it is not guaranteed that the management controllers
>> implementing pldm has https support.
>>> 3. Can you describe the use case for the tool to be run on host firmware? In my opinion, this is highly unlikely though it can be run from host user space.
>> This might not be a typical use-case to run pldmtool from host firmware.
>> I was curious to know if someone will be interested to do this. But we
>> do see a possibility of running it from Host OS targeting the BMC, just
>> like ipmitool can be run from the host targeting the BMC via KCS/BT
>> interfaces.
>>> Thanks,
>>> Supreeth
>>> -----Original Message-----
>>> From: Tom Joseph <tomjose at linux.vnet.ibm.com>
>>> Sent: Monday, February 18, 2019 4:09 AM
>>> To: OpenBMC Maillist <openbmc at lists.ozlabs.org>; Supreeth Venkatesh <Supreeth.Venkatesh at arm.com>; Alexander Amelkin <a.amelkin at yadro.com>; benwei at fb.com
>>> Subject: Proposal for pldmtool
>>>
>>> Hi All,
>>>
>>> I wanted to put down initial thoughts on "pldmtool" which is a utility for controlling PLDM enabled devices. The naming of the utility was influenced by ipmitool which is a client utility to control IPMI enabled devices. The pldmtool acts as the requester and sends the PLDM message to target any PLDM enabled device. The PLDM response message is processed and expressed in human readable format.  This proposal needs to be considered on the basis of the pldm design (https://github.com/openbmc/docs/blob/master/designs/pldm-stack.md).
>>> These are possible pldmtool usage scenarios.
>>>
>>> * pldmtool can run on OpenBMC and can target the PLDM daemon. PLDM daemon will have a D-Bus interface to accept PLDM requests.
>>> * pldmtool can target other management controllers connected to BMC implementing PLDM stacks.
>>> * A provision to run pldmtool targeting OpenBMC over a custom network port and route the request to the PLDM daemon.
>>>
>>> These are the some of the salient features in the pldmtool that
>>>
>>> * Provide user friendly command options
>>> * Debug options to print detailed PLDM messages.
>>> * Leverage libmctp and libpldm library getting developed for communicating with MCTP layer and for encoding/decoding PLDM messages.
>>> (https://github.com/openbmc/pldm, https://github.com/jk-ozlabs/libmctp)
>>>
>>> The host firmware stacks typically have runtime constraints. If there is interest in having pldmtool run on host firmware then pldmtool will have to be written in C. Apart from this consideration the natural choice will be to develop this in modern C++.
>>>
>>> This mail is a feeler to seek the interests of the community. I will be keen to follow-up this with a design template.
>>>
>>> Thanks,
>>> Tom
>>>
>>> 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.
>



More information about the openbmc mailing list