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 75B8537B1 for ; Wed, 25 May 2016 13:27:39 +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:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1b5WyJ-0005vP-Us; Wed, 25 May 2016 07:27:37 -0400 Date: Wed, 25 May 2016 07:27:26 -0400 From: Neil Horman To: Panu Matilainen Cc: dev@dpdk.org, Bruce Richardson , Thomas Monjalon , Stephen Hemminger Message-ID: <20160525112726.GA14322@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1464118912-19658-1-git-send-email-nhorman@tuxdriver.com> <5bf42f04-f7ce-7e01-71d5-0a1b96877b4f@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bf42f04-f7ce-7e01-71d5-0a1b96877b4f@redhat.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 11:27:39 -0000 On Wed, May 25, 2016 at 11:32:06AM +0300, Panu Matilainen wrote: > 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. > Well, don't thank me, I'm not a big fan of it, I just don't see a way around it at this point, not without some heuristic thats going to be wrong half the time. > > * 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 > thanks Neil > 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 - >