On Tue, Jun 16, 2020 at 06:18:13AM -0600, Todd C. Miller wrote: > On Tue, 16 Jun 2020 12:48:58 +0200, Martin Pieuchot wrote: > > > The diff below implements DragonFly's approach of adding a new kind of > > filter, EVFILT_EXCEPT, to report such conditions. This extends the > > existing kqueue interface which is questionable. On the one hand this > > allows userland programs to use kevent(2) to check for this conditions. > > One the other hand this is not supported by any other BSD and thus non > > standard. > > Actually, it looks like macOS uses EVFILT_EXCEPT too. They were > the first OS to implement poll in terms of kqueue as far as I know. > I don't think there is a problem extended kqueue with EVFILT_EXCEPT.
macOS also has EV_OOBAND as an analog to EV_EOF, but the addition caught people by surprise: https://bugs.chromium.org/p/chromium/issues/detail?id=437642 https://nvd.nist.gov/vuln/detail/CVE-2015-1105 I would guess EV_OOBAND was intended to behave like POLLRDBAND, and considering that POLLRDBAND is in POLLIN it made some sense to signal EV_OOBAND by default. Likewis for EV_EOF, which is also always signaled, though ignoring it is benign. It all seems logical (notwithstanding the inability to mask it), but only if that was the behavior from day 1. Surprising people with it doesn't seem like a good idea.
