Re: Read FRU of host through ipmi in Entity manager.

[Andrei Kartashev <a.kartashev@yadro.com>]

>     Minor amendment again.  I'd much rather the IPMBSensor daemon
> simply
>     create the same interface that fru device does, rather than
> adding
>     IPMB logic to FruDevice.  In this way, platforms that don't have
> IPMB
>     don't need to include the feature at all.  Also, all the IO can
> be
>     managed in one place.
>     
> https://github.com/openbmc/dbus-sensors/blob/master/src/IpmbSensor.cpp
>     Ideally, your IPMB device would also have an SDR that details
> what
>     FRUs and sensors exist, so that the inventory can be read and
> posted
>     to DBus at startup.  If they don't then we might need a static
> mapping
>     from an EM config once the device on the other end is detected
> via get
>     device ID.
> 
> I agree with Ed here, all ipmb related interfaces should be
> implemented here.
> 


I disagree here.
First of all, IPMBSensor located in dbus-sensors package and it is
suppose to handle SENSORS. FRU is not sensor, it would be big illogical
mistake to put FruDevice code there.
Then there are already number of places in OpenBMC and related projects
uses FRU and implements encoding/decoding by its own. I already spend
lot of time debugging different behaviour of FruDevice and ipmitool...
You propose to fragment FRU handling code even more and I against this.
We at least should then extract data-source independent code from
FruDevice to a kind of library to use from different daemons. But I
prefer to do opposite - extract impb i/o code to library and use it
from both IPMBSensor and FruDevice.

-- 
Best regards,
Andrei Kartashev