I think it's just one of those cases where it would be highly non-trivial and inefficient to put all of the checks in APR, simply due to the real-world nature of the bugs, but that at the same time there is a clear benefit available to those willing to take the time to read the manual and decide for themselves if it will work in their situation.
For those OSes that have a large number of cases where sendfile() doesn't work, then we can disable sendfile() rather than checking for these cases. However, your position mandates that the admins must do a lot of legwork to understand if their OS has issues or not. It's not always obvious what the corner cases are here: I'm in favor of placing that work in APR - where there are people willing to produce appropriate patches to relax the restrictions on that OS.
One fstatfs call will allow us to detect the FS issues we've seen: either blacklist or whitelist fstypes per OS, I don't much care. And, we can check for IPv6 sockets on Linux. Ideally, we'd have some way of minimizing the need for fstatfs calls, but even without a cache of some sort (I don't know how slow or fast fstatfs tends to be), that's a fair price to pay for correctness and a viable attempt to maintain zero-copy performance.
Yet, I believe most of these are outright OS or driver bugs that will, over the long run, be fixed upstream. If your OS or driver maintainers don't fix problems with their software, then you have other issues. -- justin
