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 88F879AEE for ; Mon, 16 May 2016 22:41:43 +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 1b2PKc-0004Oq-5L; Mon, 16 May 2016 16:41:40 -0400 From: Neil Horman To: dev@dpdk.org Cc: Neil Horman , Bruce Richardson , Thomas Monjalon , Stephen Hemminger , Panu Matilainen Date: Mon, 16 May 2016 16:41:23 -0400 Message-Id: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> X-Mailer: git-send-email 2.5.5 X-Spam-Score: -1.0 (-) X-Spam-Status: No Subject: [dpdk-dev] [PATCH 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: Mon, 16 May 2016 20:41:43 -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 two variables: this_pmd_name this_pmd_table 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 [] __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 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 CC: Bruce Richardson CC: Thomas Monjalon CC: Stephen Hemminger CC: Panu Matilainen