Rather than defining "rte_" versions of these functions, is it possible
just to provide the unprefixed definitions of them for internal use?
While this probably won't work for any functions used in public headers,
for any functions only used in C files, we can use meson to detect the
presence of the standard function and set a macro flag for the compatiblity
version if not present. This is something we already support for the
strlcpy/strlcat functions from libbsd, and it basically allows the
well-known (and loved?) functions to be used directly, and saves DPDK
developers having to worry about what "standard" functions can be used
directly, and which can't.
Hi Bruce,
You're asking a really good question here that highlights a fundamental
issue:
Does the DPDK code base have an implied POSIX dependency, or should it only
depend upon the standard C library and 'rte_ ' functions. This hasn't
been an
issue before, but Windows isn't 'POSIX' based.
Using "well-known" names for missing functions is ok where the definitions
are in private header files, but if the headers are public, or the
implementation
is better done in a C file, then there can be a clash with the
application which
is likely dealing with the same issues.
There seem to be two viable approaches to handling this:
1. Expect the platform to provide POSIX semantic (through an external
library
such as Cygwin). That way it becomes "an 'external' problem" and the
DPDK
can use the "well-known" names and expected behaviour.
2. Provide the missing functionality, but wrap it in 'internal' header
files
and 'rte_' versions to avoid link errors. This is the approach that
Dmitry has
taken based on the guidance we've received.
For background, the approach I've taken with adding Windows support to SPDK
is to create an 'external' library (https://wpdk.github.io) with header
files that
provide the missing POSIX functionality and functions with a prefix to
avoid link
errors. As a result, the whole of SPDK can now build and run unchanged.
Regards,
Nick
