>> It also is a wrong way to build self-configuration; such a test is >> vulnerable to both false positives and false negatives. It should >> be reported upstream as a bug. Much righter is to test whether >> epoll, if present, produces the behaviour the program expects in the >> uses it makes of it.
> As Linux introduced epoll (or so I think) I think it's appropriate -- > absent a SUS specification -- to assume it works as under Linux? Probably. But that wasn't what was being suggested, at least not as I read it. Here's fuller context: >>>>> The problem is third-party software assumes epoll == Linux, >>>> Software that makes stupid assumptions will never go away. >>>> Is it better to work around it (not ship epoll.h), or to get it >>>> fixed (report it upstream as the bug it is)? [...] >>> I don't really see it as a bug. You'd have to have all those >>> problems have configure logic that says >>> if we find an epoll implementation, then we have a list of >>> operating systems that have implemented an epoll that has >>> different semantics and we have to reject it >>> It seems far more reasonable to say that if an OS implements a >>> different epoll, then it should call it something else. >> [...] It also is a wrong way to build self-configuration; [...] What I was arguing is not "NetBSD should have epoll with different semantics" but "the problematic programs would have to have a configure test with a blacklist of OS/version pairs". Blacklisting by OS/version is what I was arguing against. > How would you argue if some other OS was to introduce something > called kqueue with semantics different from FreeBSD? I would still say that a configure test that blacklisted them by OS/version is a broken test. I say it should either blindly assume the semantics it expects or it should test for the semantics it cares about, depending on the philosophy stance its authors prefer. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
