[dpdk-dev] [PATCHv7 1/6] pmdinfogen: Add buildtools and pmdinfogen utility

Neil Horman nhorman at tuxdriver.com
Thu Jun 16 16:41:18 CEST 2016


On Thu, Jun 16, 2016 at 05:06:49PM +0300, Panu Matilainen wrote:
> On 06/16/2016 04:33 PM, Neil Horman wrote:
> > On Thu, Jun 16, 2016 at 03:29:57PM +0300, Panu Matilainen wrote:
> > > On 06/09/2016 08:46 PM, Neil Horman wrote:
> > > > pmdinfogen is a tool used to parse object files and build json strings for
> > > > use in later determining hardware support in a dso or application binary.
> > > > pmdinfo looks for the non-exported symbol names this_pmd_name<n> and
> > > > this_pmd_tbl<n> (where n is a integer counter).  It records the name of
> > > > each of these tuples, using the later to find the symbolic name of the
> > > > pci_table for physical devices that the object supports.  With this
> > > > information, it outputs a C file with a single line of the form:
> > > > 
> > > > static char *<pmd_name>_driver_info[] __attribute__((used)) = " \
> > > > 	PMD_DRIVER_INFO=<json string>";
> > > > 
> > > > Where <pmd_name> is the arbitrary name of the pmd, and <json_string> is the
> > > > json encoded string that hold relevant pmd information, including the pmd
> > > > name, type and optional array of pci device/vendor ids that the driver
> > > > supports.
> > > > 
> > > > This c file is suitable for compiling to object code, then relocatably
> > > > linking into the parent file from which the C was generated.  This creates
> > > > an entry in the string table of the object that can inform a later tool
> > > > about hardware support.
> > > > 
> > > > 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>
> > > > ---
> > > 
> > > Unlike earlier versions, pmdinfogen ends up installed in bindir during "make
> > > install". Is that intentional, or just a side-effect from using
> > > rte.hostapp.mk? If its intentional it probably should be prefixed with dpdk_
> > > like the other tools.
> > > 
> > Im not sure what the answer is here.  As you can see, Thomas and I argued at
> > length over which makefile to use, and I gave up, so I suppose you can call it
> > intentional.  Being in bindir makes a reasonable amount of sense I suppose, as
> > 3rd party developers can use it during their independent driver development.
> 
> Right, it'd be useful for 3rd party driver developer, so lets consider it
> intentional :)
> 
> > I'm not sure I agree with prefixing it though.  Given that the hostapp.mk file
> > installs everything there, and nothing that previously used that make file had a
> > dpdk_ prefix that I can tell, I'm not sure why this would.  pmdinfogen seems
> > like a pretty unique name, and I know of no other project that uses the term pmd
> > to describe anything.
> 
> I agree about "pmd" being fairly unique as is, but if pmdinfo is dpdk_
> prefixed then this should be too, or neither should be prefixed. I dont
> personally care which way, but it should be consistent.
> 
I caved on the pmdinfo issue, I guess I'll cave here too.


More information about the dev mailing list