Comment by vacuity
7 days ago
I have a general distaste for transparent policies, which I always find to fall short for some use case. In this case, the sender would know best what to do with their message. Moreover, for small buffers, page remapping won't be an optimization. I recommend reflecting this as an alternative send interface.
The lower a transparent policy lies in the OS, the worse it contorts the system. Even mechanisms necessarily constrain policy, if only slightly. I strongly believe that microkernels will only be improved by adhering ever closer to true minimality. If backwards compatibility is important, put the policy in a library. But I think transparent policies are generally advisable only when user feedback indicates benefit.
If you want your send/receive/reply mechanism to work transparently across a network then you have already made many such decisions and likely this one will just appear as an optimization in case both client and server are local.
I agree that the decisions will likely be made in the end, but I want to say that the decisions should be made as high/late as possible. It is important to note not just that a decision has been made, but where it has been made, for any dynamic system. This will determine things like overhead or maintenance burden.
Contrary to QNX, I'm not entirely convinced that network transparency by default is ultimately best, though that is a separate concern.