[dpdk-dev] [PATCHv4 0/5] Implement pmd hardware support exports

[Panu Matilainen]

On 05/24/2016 10:41 PM, Neil Horman wrote:
> Hey all-
> 	So heres attempt number 2 at a method for exporting PMD hardware support
> information.  As we discussed previously, the consensus seems to be that pmd
> information should be:
>
> 1) Able to be interrogated on any ELF binary (application binary or individual
> DSO)
> 2) Equally functional on statically linked applications or on DSO's
> 3) Resilient to symbol stripping
> 4) Script friendly
> 5) Show kernel dependencies
> 6) List driver options
> 7) Show driver name
> 8) Offer human readable output
> 9) Show DPDK version
> 10) Show driver version
> 11) Allow for expansion
> 12) Not place additional build environment dependencies on an application
>
[...]
> v4)
>  * Modified the operation of the -p option. As much as I don't like implying
> that autoloaded pmds are guaranteed to be there at run time, I'm having a hard
> time seeing how we can avoid specifying the application file to scan for the
> autoload directory.  Without it we can't determine which library the user means
> in a multiversion installation
>  * Cleaned up the help text
>  * Added a rule for an install target for pmdinfo
>  * Guarded against some tracebacks in pmdinfo
>  * Use DT_NEEDED entries to get versioned libraries in -p mode

Thank you! That's exactly what I've been asking for all along.

>  * Fixed traceback that occurs on lack of input arguments
>  * Fixed some erroneous macro usage in drivers that aren't in the default build
>
> Signed-off-by: Neil Horman <nhorman at tuxdriver.com>
> CC: Bruce Richardson <bruce.richardson at intel.com>
> CC: Thomas Monjalon <thomas.monjalon at 6wind.com>
> CC: Stephen Hemminger <stephen at networkplumber.org>
> CC: Panu Matilainen <pmatilai at redhat.com>

/me happy now, so:

Acked-by: Panu Matilainen <pmatilai at redhat.com>

As always there might be some refining to do as we get more experience 
with it but it seems like a fine starting point to me.

	- Panu -