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

Nick Connolly nick.connolly at mayadata.io
Wed Mar 31 23:05:11 CEST 2021


> 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.

Regards,
Nick



More information about the dev mailing list