31/03/2021 23:05, Nick Connolly: > > > 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.
