[dpdk-dev] [PATCH v2 1/7] eal: add wrappers for POSIX string functions

[Nick Connolly]

> 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