From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 019BB2C5D for ; Wed, 25 May 2016 10:32:10 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3FE007F0A2; Wed, 25 May 2016 08:32:09 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-5-77.ams2.redhat.com [10.36.5.77]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4P8W7bG009308; Wed, 25 May 2016 04:32:07 -0400 To: Neil Horman , dev@dpdk.org References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1464118912-19658-1-git-send-email-nhorman@tuxdriver.com> Cc: Bruce Richardson , Thomas Monjalon , Stephen Hemminger From: Panu Matilainen Message-ID: <5bf42f04-f7ce-7e01-71d5-0a1b96877b4f@redhat.com> Date: Wed, 25 May 2016 11:32:06 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <1464118912-19658-1-git-send-email-nhorman@tuxdriver.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 25 May 2016 08:32:09 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCHv4 0/5] 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, 25 May 2016 08:32:10 -0000 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 > CC: Bruce Richardson > CC: Thomas Monjalon > CC: Stephen Hemminger > CC: Panu Matilainen /me happy now, so: Acked-by: Panu Matilainen 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 -