On 05/20/2016 05:06 PM, Neil Horman wrote: [...] > Look, I think we're simply not going to agree on this issue at all. What > about > this in the way of compromise. I simply am not comfortable with automatically > trying to guess what hardware support will exist in an application based on > the > transient contents of a plugin directory, because of all the reasons we've > already gone over, but I do understand the desire to get information about > what > _might_ be automatically loaded for an application. what if we added a > 'plugin > mode' to pmdinfo. In this mode you would dpecify a dpdk installation directory > and an appropriate mode option. When specified pmdinfo would scan librte_eal > in > the specified directory, looking for an exported json string that informs us > of > the configured plugin directory. If found, we iterate through all the > libraries > there displaying hw support. That allows you to query the plugin directory > for > available hardware support, while not implying that the application is > guaranteed to get it (because you didn't specifically state on the command > line > that you wanted to know about the applications hardware support).
That brings it all to one tiny step away from what I've been asking: have the plugin mode automatically locate librte_eal from an executable. So I'm not quite sure where the compromise is supposed to be here :) I do appreciate wanting to differentiate between "physically" linked-in and runtime-loaded hardware support, they obviously *are* different from a technical POV. But its also a difference an average user might not even know about or understand, let alone care about, they just want to know "will it work?" - Panu -