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

[James Feist]

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.