use C linkage where appropriate in headersAssure that 'extern "C" { /../ }' do not cover files included from aparticular header file, and address minor issues resulting from thischange of order.
use C linkage where appropriate in headersAssure that 'extern "C" { /../ }' do not cover files included from aparticular header file, and address minor issues resulting from thischange of order.Dealing with C++ should delegate to the individual include file level,rather than being imposed by the user of that file. For example,forcing C linkage prevents __Generic macros being replaced withoverloaded static inline functions in C++ translation units.Eliminate 'extern "C"' from files which do not declare any symbols(e.g., only macros or struct types).On the other hand, the headers check is too naive in assuming that allheaders must contain a 'extern "C"'. Such a check was added in commit1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards").Since this current change results in many headers not containing sucha token, remove the check for 'extern "C"' until we have a betterimplementation.Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>Acked-by: Morten Brørup <mb@smartsharesystems.com>Signed-off-by: David Marchand <david.marchand@redhat.com>
show more ...
eal: add missing C++ guardsSome public header files were missing 'extern "C"' C++ guards,and couldn't be used by C++ applications. Add the missing guards.Fixes: af75078fece3 ("first public relea
eal: add missing C++ guardsSome public header files were missing 'extern "C"' C++ guards,and couldn't be used by C++ applications. Add the missing guards.Fixes: af75078fece3 ("first public release")Fixes: 7f3aa0863903 ("eal: introduce bit operations API")Fixes: 166a743c53fa ("compat: add infrastructure to support symbol versioning")Fixes: 8f40ee0734c8 ("eal/x86: get hypervisor name")Fixes: 75583b0d1efd ("eal: add keep alive monitoring")Fixes: 88701645c98c ("eal: move interrupt type out of igb_uio")Fixes: f04519d8092e ("lib: add missing include dependencies")Fixes: f58880682c81 ("trace: implement register API")Fixes: 428eb983f5f7 ("eal: add OS specific header file")Cc: stable@dpdk.orgSigned-off-by: Brian Dooley <brian.dooley@intel.com>Acked-by: Bruce Richardson <bruce.richardson@intel.com>Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
eal: remove sys/queue.h from public headersCurrently there are some public headers that include 'sys/queue.h', whichis not POSIX, but usually provided by the Linux/BSD system library.(Not in POSI
eal: remove sys/queue.h from public headersCurrently there are some public headers that include 'sys/queue.h', whichis not POSIX, but usually provided by the Linux/BSD system library.(Not in POSIX.1, POSIX.1-2001, or POSIX.1-2008. Present on the BSDs.)The file is missing on Windows. During the Windows build, DPDK uses abundled copy, so building a DPDK library works fine. But when OVS or otherapplications use DPDK as a library, because some DPDK public headersinclude 'sys/queue.h', on Windows, it triggers an error due to no suchfile.One solution is to install the 'lib/eal/windows/include/sys/queue.h' intoWindows environment, such as [1]. However, this means DPDK exports thefunctionalities of 'sys/queue.h' into the environment, which might causesymbols, macros, headers clashing with other applications.The patch fixes it by removing the "#include <sys/queue.h>" fromDPDK public headers, so programs including DPDK headers don't dependon the system to provide 'sys/queue.h'. When these public headers usemacros such as TAILQ_xxx, we replace it by the ones with RTE_ prefix.For Windows, we copy the definitions from <sys/queue.h> to rte_os.hin Windows EAL. Note that these RTE_ macros are compatible with<sys/queue.h>, both at the level of API (to use with <sys/queue.h>macros in C files) and ABI (to avoid breaking it).Additionally, the TAILQ_FOREACH_SAFE is not part of <sys/queue.h>,the patch replaces it with RTE_TAILQ_FOREACH_SAFE.[1] http://mails.dpdk.org/archives/dev/2021-August/216304.htmlSuggested-by: Nick Connolly <nick.connolly@mayadata.io>Suggested-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>Signed-off-by: William Tu <u9012063@gmail.com>Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>Acked-by: Narcisa Vasile <navasile@linux.microsoft.com>
lib: remove librte_ prefix from directory namesThere is no reason for the DPDK libraries to all have 'librte_' prefix onthe directory names. This prefix makes the directory names longer and alsom
lib: remove librte_ prefix from directory namesThere is no reason for the DPDK libraries to all have 'librte_' prefix onthe directory names. This prefix makes the directory names longer and alsomakes it awkward to add features referring to individual libraries in thebuild - should the lib names be specified with or without the prefix.Therefore, we can just remove the library prefix and use the library'sunique name as the directory name, i.e. 'eal' rather than 'librte_eal'Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>