From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id A824168FC for ; Wed, 18 May 2016 23:08:27 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1b38hW-0001I7-MU; Wed, 18 May 2016 17:08:23 -0400 From: Neil Horman To: dev@dpdk.org Cc: Neil Horman , Bruce Richardson , Thomas Monjalon , Stephen Hemminger , Panu Matilainen Date: Wed, 18 May 2016 17:08:03 -0400 Message-Id: <1463605687-649-1-git-send-email-nhorman@tuxdriver.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: [dpdk-dev] [PATCHv2 0/4] Implement pmd hardware support exports X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 21:08:28 -0000 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 a variable: this_pmd_name= "name" Based on the unique name string pointed to by the above variable, we can query for an arbitrary number of other symbols following the pattern: _ Where tag is some well known identifier for information we wish to export B) Added a utility called pmdinfogen. 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 [] __attribute__((used)) = "PMD_DRIVER_INFO="; The is arbitrary, as its static and not referenced. The relevant bit is the string value assigned to it. The 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 pmdinfo.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 boxes: 1) Impervious to stripping 2) Works on static and dynamic binaries 3) Human and script friendly 4) Allows for expansion 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. Change Notes: v2) * Made the export macros a bit easier to expand * Added a macro to optionally export command line strings * Renamed utilties to be more appropriate (pmdinfo -> pmdinfogen, pmd_hw_support.py -> pmdinfo.py) * Added search capabilities to pmdinfo.py so that we search for libraries linked using DT_NEEDINFO entries. We search DT_RUNPATH, LD_LIBRARY_PATH, /usr/lib and /lib * Added serch abilities if the specified binary to pmdinfo isn't found, we search LD_LIBRARY_PATH, /usr/lib and /lib * Added an option to pmdinfo.py to pretty-print hardware support info using the pci.ids database Signed-off-by: Neil Horman CC: Bruce Richardson CC: Thomas Monjalon CC: Stephen Hemminger CC: Panu Matilainen