Re: [dpdk-dev] [PATCH v6 3/5] eal: make OS shims internal

31/03/2021 23:05, Nick Connolly:

quoted

This shim could have been convenient for applications.
If not named "internal", we could export the header file
and allow apps including it.

Otherwise the app can recreate this file on its side,
it is not a big deal.
Opinions?

Based on my experience with SPDK, I believe this would get messy
very quickly.

For example, a common usage is to redefine close to _close.
If the application is going to use sockets without requiring changes,
then a fake fd is needed to represent a socket and close has to
handle it as well ... which will clash with the 'simplistic' redefinition
to _close, so we'd need some way of turning these on/off
individually.

I think there are really only two models that are viable - either an
external POSIX layer that is used by everything (in the general case,
Cygwin would be an example), or a private implementation that is
not exposed publicly.

Keeping the implementation private is not just about keeping
POSIX out of the headers. It's about avoiding conflicts with the
application; e.g. making sure that any signal implementation can
co-exist with the application.

I don't understand your point.
I am just proposing to allow some apps to explicitly include the shim
for their convenience in case they are fully based on DPDK and
understand the risk of conflict with some other code.