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 699DE2C45 for ; Wed, 25 May 2016 19:47:31 +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 1b5ctz-0008Oj-EH; Wed, 25 May 2016 13:47:29 -0400 Date: Wed, 25 May 2016 13:47:21 -0400 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Bruce Richardson , Stephen Hemminger , Panu Matilainen Message-ID: <20160525174721.GE14322@hmsreliant.think-freely.org> References: <1463431287-4551-1-git-send-email-nhorman@tuxdriver.com> <1464118912-19658-1-git-send-email-nhorman@tuxdriver.com> <1464118912-19658-6-git-send-email-nhorman@tuxdriver.com> <1484190.9fzbW2DJJe@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484190.9fzbW2DJJe@xps13> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCHv4 5/5] pmdinfo.py: Add tool to query binaries for hw and other support information 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 17:47:31 -0000 On Wed, May 25, 2016 at 07:22:39PM +0200, Thomas Monjalon wrote: > 2016-05-24 15:41, Neil Horman: > > Note that, in the case of dynamically linked applications, pmdinfo.py will scan > > for implicitly linked PMDs by searching the specified binaries .dynamic section > > for DT_NEEDED entries that contain the substring librte_pmd. > > I don't know any DPDK app dynamically linked with a PMD (with DT_NEEDED). I know lots of them, they're all in the dpdk. everything under app that uses a virutal device links at link time to librte_pmd_bonding and librte_pmd_pipe (and a few others), because they have additional apis that they need to resolve at load time. > However it is a good idea to handle this case. > But relying on the name assumption "librte_pmd" is really weak. > > > + $(Q)$(call rte_symlink, $(DESTDIR)$(datadir)/tools/pmdinfo.py, \ > > + $(DESTDIR)$(bindir)/pmdinfo) > > I think we must prefix the tool name with dpdk. > What about dpdk-objinfo or dpdk-pmdinfo? > > > +from elftools.elf.elffile import ELFFile > > +from elftools.elf.dynamic import DynamicSection, DynamicSegment > > +from elftools.elf.enums import ENUM_D_TAG > > +from elftools.elf.segments import InterpSegment > > +from elftools.elf.sections import SymbolTableSection > > Should it be possible to implement pmdinfogen with this > Python library? > Sure, but that really doesn't buy us anything, as its already implemented in C. In fact, I would assert its harmful, because it implies that the build environment needs to have python installed, as well as the pyelftools library, which we don't need if we build from C. > I'll probably comment on the pmdinfo script details later. > Just knowing you did a tool is enough to assert that it is a good step :) > Thanks >