[dpdk-dev] [PATCH 0/4] Implement pmd hardware support exports

[Neil Horman]

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

I added item 12 myself, because I don't think its reasonable to require
applications to use a specific linker script to get hardware support information
(which precludes the use of a special .modinfo section like the kernel uses)

However, we still can use some tricks from the kernel to make this work.  In
this approach, what I've done is the following:

A) Modified the driver registration macro to also define two variables:
this_pmd_name<n>
this_pmd_table<n>

The second is optional, and omitted for virtual devices.  These symbols are
static, and marked as used, so they will always be emitted by the compiler, and
with their well known names, easy to search for in an object (.o) file

B) Added a utility called pmdinfo.  This utility is not meant for general use,
but rather is used by the dpdk build environment itself when compiling pmds.
for each object that uses the PMD_REGISTER_DRIVER macro, this utiity is run.  It
searches for the symbols in (A), and using those, extracts the hardware support
info, and module name from the object, using that to produce a new c file
containing a single variable in the following format:

static const char <name>[] __attribute__((used)) = "PMD_DRIVER_INFO=<json>";

The <name> is arbitrary, as its static and not referenced.  The relevant bit is
the string value assigned to it.  The <json> is a json encoded string of the
extracted hardware support information pmdinfo found for the corresponding
object.  This C file is suitable for compilation and relocatable linking back
into the parent object file.  The result of this operation is that the object
string table now contains a string that will not e removed by stripping, whos
leading text (PMD_DRIVER_INFO) can be easily searched for at any time weather
the symbol referring to it is stripped or not.

C) Added a utilty called pmd_hw_info.py.  This python script, searches the
string table of the .rodata section of any provided ELF file looking for the
PMD_DRIVER_INFO prefix on a string.  When found, it will interpret the remainder
of the string as json, and output the hardware support for that ELF file (if
any).


This approach ticks most of the above major boxes:
1) Impervious to stripping
2) Works on static and dynamic binaries
3) Human and script friendly
4) Allows for expansion
5) Doesn't require additional build environment needs for applications

Because of (4) the other items should be pretty easy to implement, as its just a
matter of modifying the macros to export the info, pmdinfo to encode it to json,
and pmd_hw_support.py to read it.  I'm not adding them now, as theres alot of
rote work to do to get some of them in place (e.g. DPDK has no current global
VERSION macro, drivers don't have a consistent version scheme, command line
strings have to be built for each driver, etc).  But once this is accepted,
those items can be done as time allows and should be fairly easy to implement.


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>