When creating the symlinks for header files to the include folder, the
relpath script dereferenced all symlinks. This made it impossible to
have file A.h renamed to B.h and then symlinked back to its original
name. This is useful to be able to do when refactoring or reworking
a library. Change this so that we just use the dirname of the path from
readlink, we can use the basename as it was originally, even if it was a
symlink.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Coverity reports a forward null dereference from a for loop
that works with a variable previously tested for null that had no error
handling or condition to prevent it. Pretty obvious fix below.
Coverity issue: 139593
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
There is already a directory buildtools for pmdinfogen used by
the build system. The scripts used in makefiles are moved here.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Tested-by: Ferruh Yigit <ferruh.yigit@intel.com>
Add a new macro RTE_PMD_REGISTER_KMOD_DEP() that allows a driver to
declare the list of kernel modules required to run properly.
Today, most PCI drivers require uio/vfio.
Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
pmdinfogen has a bug in which, during build, it pulls in rte_byteorder.h to
obtain the rte macros for byteswapping between the cpu byte order and big or
little endian. Unfortunately, pmdinfogen is a tool that is only meant to be run
during the build of dpdk components, and so, it runs on the host. In cross
compile environments however, the rte_byteorder.h is configured using a target
cpu, who's endianness may differ from that of the host, leading to improper
swapping.
The fix is to use host system defined byte swapping routines rather than the
dpdk provided routines. Note that we are using non posix compliant routines, as
the posix compliant api only addresses 16 and 32 bit swaps, and we also need 64
bit swaps. Those macros exist (via endian.h), but BSD and Linux put that header
in different locations so some ifdeffery is required.
Tested successfully by myself on Linux and BSD systems.
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
Compile error:
CC mlx5.o.pmd.o
mlx5.o.pmd.c:1:227:
error: no newline at end of file [-Werror,-Wnewline-eof]
...__attribute__((used)) = "PMD_INFO_STRING= {...}";
^
Produced with clang 3.8.0 and MLX5_PMD and MLX5_DEBUG
config options enabled.
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
The following tools may be installed system-wide.
It may be cleaner and more convenient to find them with the same
dpdk- prefix (especially for autocompletion).
Moreover, the script dpdk_nic_bind.py deserves a new name because it is
not restricted to NICs and can be used for e.g. crypto.
These files are renamed:
pmdinfogen -> dpdk-pmdinfogen
pmdinfo.py -> dpdk-pmdinfo.py
dpdk_pdump -> dpdk-pdump
dpdk_proc_info -> dpdk-procinfo
dpdk_nic_bind.py -> dpdk-devbind.py
setup.sh -> dpdk-setup.sh
The tools pmdinfogen, pmdinfo.py and dpdk_pdump are new in 16.07.
The scripts dpdk_nic_bind.py and setup.sh may have been used with
previous releases by end users. That's why a symbolic link still
provide the old name in the installed tools directory.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
error on compilation caused by missing include for libgen.h.
buildtools/pmdinfogen/pmdinfogen.c:402:4: error:
implicit declaration of function 'basename' is invalid in C99
basename(argv[0]));
Fixes: 840e5dfea3 ("pmdinfogen: fix usage message")
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
The name of the tool is pmdinfogen.
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
When compiled with a standard clang, pmdinfogen can raise a warning:
buildtools/pmdinfogen/pmdinfogen.c:365:1: warning:
control reaches end of non-void function
Actually there can be more warnings with stricter compilers.
In order to catch them early and fix most of them, the DPDK standard flags
WERROR_FLAGS are used.
The warnings fixed are:
no previous prototype for ...
no return statement in function returning non-void
variable ‘secstrings’ set but not used
‘sec_name’ defined but not used
‘get_symbol_index’ defined but not used
pointer of type ‘void *’ used in arithmetic
Fixes: 98b0fdb0ff ("pmdinfogen: add buildtools and pmdinfogen utility")
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
pmdinfogen is a tool used to parse object files and build json strings for
use in later determining hardware support in a dso or application binary.
pmdinfo looks for the non-exported symbol names this_pmd_name<n> and
this_pmd_tbl<n> (where n is a integer counter). It records the name of
each of these tuples, using the later to find the symbolic name of the
pci_table for physical devices that the object supports. With this
information, it outputs a C file with a single line of the form:
static char *<pmd_name>_driver_info[] __attribute__((used)) = " \
PMD_DRIVER_INFO=<json string>";
Where <pmd_name> is the arbitrary name of the pmd, and <json_string> is the
json encoded string that hold relevant pmd information, including the pmd
name, type and optional array of pci device/vendor ids that the driver
supports.
This c file is suitable for compiling to object code, then relocatably
linking into the parent file from which the C was generated. This creates
an entry in the string table of the object that can inform a later tool
about hardware support.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Panu Matilainen <pmatilai@redhat.com>
Acked-by: Remy Horton <remy.horton@intel.com>
