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 -
