[dpdk-dev] [PATCHv4 5/5] pmdinfo.py: Add tool to query binaries for hw and other support information

Neil Horman nhorman at tuxdriver.com
Wed May 25 19:47:21 CEST 2016


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
> 


More information about the dev mailing list