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

[Brad Bishop]

> On Nov 11, 2019, at 4:21 PM, James Feist <james.feist at linux.intel.com> wrote:
> 
> On 11/11/19 12:47 PM, Brad Bishop wrote:
>>> On Nov 11, 2019, at 3:06 PM, James Feist <james.feist at linux.intel.com> wrote:
>>> 
>>> 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?
>> None other than continuing to support the existing application.
>> Now that I think about it, I could probably re-work the existing application that uses the parsing logic to instead just call the fru-device DBus API (removing the need to expose the parsing logic via shared library).  Does that seem better?
> 
> I think that sounds good.
> 
>>> 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.
>> Any issue with support for multiple formats at the same time?
> 
> Only if they conflict somehow. I don't know enough about VPD to determine that. IPMI FRU format requires a specific header that we check to determine if it's an IPMI FRU. If VPD matches this header, then we won't be able to tell which parsing algorithm to use, unless you know of some other way to tell. I guess we could run the full parse on both as well, but the header check was mostly there to avoid scanning something too much that isn't a fru. If they can co-exist, that'd be preferable. If they collide we can do a build switch was my thought.

Great!  I’m pretty sure the headers are not compatible and thus the code should be able to figure it out at a glance.

thanks James!