2016-05-25 13:47, Neil Horman: > 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.
Oh yes! you are right. > > 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. Right
