entity-manager: adding additional fru formats to fru-device

[James Feist]

On 11/11/19 11:59 AM, Brad Bishop wrote:
> 
> 
>> On Nov 11, 2019, at 2:48 PM, James Feist <james.feist at linux.intel.com> wrote:
>>
>> On 11/11/19 11:43 AM, Brad Bishop wrote:
>>> Hi James
>>> At the OSFC we chatted a little bit about adding support for other fru data formats to fru-device.  I’d like to get started on that.
>>> For background and reference at IBM we call this sort of data “vital product data” or VPD.  Just so we are all on the same page this is the same stuff as IPMI FRU format data, just a different data structure.
>>> When I look at fru-device in the context of adding support for additional data formats, the necessary interface seems to just be a set of key value pairs.  We already have an application that produces exactly that here: https://github.com/openbmc/openpower-vpd-parser
>>
>> If you already have that, then there should be no reason for you to need to use fru-device.
> 
> This application doesn’t do any discovery on its own.  It relies on udev to launch it.  Further it doesn’t create any dbus objects it just calls phosphor-inventory-manager and then exits.
> 
>> Entity-Manager probes dbus, so as long as there is key-value pairs, you should be able to make your probe
>> 'xyz.openbmc_project.MyInterface('KeyICareAbout':'ExpectedValue'). If this application can already do discovery,
> 
> It doesn’t do discovery.  It has a filename-to-parse command line argument.
> 
>> I don't think you need fru-device.  This might actually be a good excuse to pull fru-device out of the entity-manager repo, having them together makes it seem too much like they depend on each-other, which they don’t.
> 
> I think you are suggesting I simply add the discovery logic to openpower-vpd-parser, and change it from a short lived one shot application to a long running daemon?
> 
> That would certainly work but I wouldn’t mind re-using all the discovery logic in fru-device, since at the end of the day everything is exactly the same except the data structure in the eeprom.

Oh I assumed it was long living, I guess I misunderstood. Either should 
be fine. Is there any reason to make the parsing logic a shared library? 
Are you planning on reusing it in ipmi or somewhere else? The parsing 
logic could probably just be a build switch otherwise, I imagine some 
sort of binary-to-dict function that we could just create multiple of 
and compile time choose what format we want.

> 
> thx -brad
>