Make it possible to implement poll(2) on top of kqueue(2).

[ed]

Summary

It looks like EVFILT_READ and EVFILT_WRITE trigger under the same
conditions as poll()'s POLLRDNORM and POLLWRNORM as described by POSIX.
The only difference is that POLLRDNORM has to be triggered on regular
files unconditionally, whereas EVFILT_READ only triggers when not EOF.

Introduce a new flag, NOTE_FILE_POLL, that can be used to make
EVFILT_READ and EVFILT_WRITE behave identically to poll(). This flag
will be used by cloudlibc's poll() function.

Test Plan

The following set of tests for poll() pass on CloudABI:

https://github.com/NuxiNL/cloudlibc/blob/master/src/libc/poll/poll_test.c

[ed]

It is worth mentioning that although it is now possible to emulate a lot of poll(2)'s functionality, there is absolutely no support for out-of-band data, but it's also not possible to deal with entries where events == 0. It may better to abandon this route and solve this differently, by adding a separate filter; EVFILT_POLL.

Just let me know what you think and I'll work on this.

[jmg]

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

[ed]

In D3303#66768, @jmg wrote:

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

Of course. Would it make sense to #ifdef _KERNEL it and revert the man page changes? That way we can be certain that userspace won't use it.

[jmg]

In D3303#66772, @ed wrote:

In D3303#66768, @jmg wrote:

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

Of course. Would it make sense to #ifdef _KERNEL it and revert the man page changes? That way we can be certain that userspace won't use it.

I'm split on this one, only do this is you think you're likely to abandon this. There could be useful uses in userland though, for trying to integrate poll programs into kqueue.

In D3303#66760, @ed wrote:

It is worth mentioning that although it is now possible to emulate a lot of poll(2)'s functionality, there is absolutely no support for out-of-band data, but it's also not possible to deal with entries where events == 0. It may better to abandon this route and solve this differently, by adding a separate filter; EVFILT_POLL.

Just let me know what you think and I'll work on this.

RE: OOBand data, I just checked our code, and it looks like nothing in the kernel can raise {RD,WR}BAND signals, so do we need to support it?

[ed]

In D3303#66777, @jmg wrote:

In D3303#66772, @ed wrote:

In D3303#66768, @jmg wrote:

I don't see an issue w/ this, though if this is committed, but then CloudABI decided to not use it anymore, I request that it be removed.

Of course. Would it make sense to #ifdef _KERNEL it and revert the man page changes? That way we can be certain that userspace won't use it.

I'm split on this one, only do this is you think you're likely to abandon this. There could be useful uses in userland though, for trying to integrate poll programs into kqueue.

Good point. Will leave the patch the way it is right now.

In D3303#66760, @ed wrote:

RE: OOBand data, I just checked our code, and it looks like nothing in the kernel can raise {RD,WR}BAND signals, so do we need to support it?

Ah, okay. That's an interesting observation.

In my opinion OOB support is not important at all. In fact, cloudlibc's poll() doesn't even provide support for it. POLL{RD,WR}BAND are not present.