Read FRU of host through ipmi in Entity manager.

[Kumar Thangavel]

Classification: HCL Internal

Hi Ed,

     Thanks for your comments on this.

Thanks,
Kumar.

-----Original Message-----
From: Ed Tanous <ed at tanous.net>
Sent: Wednesday, September 23, 2020 1:34 AM
To: Kumar Thangavel <thangavel.k at hcl.com>
Cc: Vijay Khemka <vijaykhemka at fb.com>; openbmc at lists.ozlabs.org; Jae Hyun Yoo <jae.hyun.yoo at linux.intel.com>; Vernon Mauery <vernon.mauery at linux.intel.com>; James Feist <james.feist at linux.intel.com>; Velumani T-ERS,HCLTech <velumanit at hcl.com>; Patrick Williams <patrickw3 at fb.com>
Subject: Re: Read FRU of host through ipmi in Entity manager.

[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]

On Mon, Sep 21, 2020 at 9:44 AM Kumar Thangavel <thangavel.k at hcl.com> wrote:
>
> Classification: HCL Internal
>
> Hi All,
>
>             Thanks for your comments and suggestions.
>
>             As suggested, we are planning to implement a new process/service like  xyz.openbmc_project.IPMB.FruDevice in entity manager module to support Host FRU through ipmb rather than using dbus-sensors/ipmbsensors file.
>
>             Following are the advantages, if host FRU handling in entity manager repo.
>
>             1. All the FRU information is handling in the same repo.

But IPMB information is bifurcated in your plan.  Ideally, Fru-Device wouldn't even be in the entity-manager repo, it's there now just as an artifact of the history of how it was built.
Ok.

>             2. Entity manager Probe can work.

I'm not understanding this;  Entity manager probes can work regardless of where the code is checked in.

Ok.

>             3. All the FRU Functions are in the same repo. We can try to reuse most of the functions.

This is a valid point.  Maybe some of the functions need abstracted out into their own libraries?

Ok.

>             4. Adding Fru object to dbus handling are done.

I'm not following this point.  Are you saying that code wouldn't need duplicated?

Yes.  Planning to reuse the functions for adding fru object to dbus handling.

>             5. All FRU validations are done here like Format fru, update fru property, validate header, Fru AreaLen and checksum. We can try to reuse those validations.

See previous point about "maybe we need a library".

>
>             For scanning the /dev/ipmi-* nodes, we are thinking to use ipmb-channels.json cofig entries in entity manager repo since this config file has valid slave path and bus address.


It should be noted, there's going to need to be significantly more code added to be able to scan and parse the SDR.  I'm assuming that code alone will be larger than FruDevice is today.
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________