kern/55983: shortcomings in poll(2)

[dholland%NetBSD.org@localhost]

>Number:         55983
>Category:       kern
>Synopsis:       shortcomings in poll(2)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 09 01:15:00 +0000 2021
>Originator:     David A. Holland
>Release:        NetBSD 9.99.80 (202002008)
>Organization:
>Environment:
System: NetBSD valkyrie 9.99.49 NetBSD 9.99.49 (VALKYRIE) #0: Fri Oct  2 15:00:22 EDT 2020  dholland@valkyrie:/y/objects/usrobj-amd64/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

Some discussion in chat prompted me to look at poll(2) and it was
found wanting. I've improved it, but the following points remain (to
which I don't know the answers):

(1) Is the relationship between POLLIN/POLLOUT/POLLPRI and
POLLRDNORM/POLLWRNORM/POLLRDBAND the same in System V (and Linux) as
in NetBSD? In NetBSD these are synonyms, modulo POLLIN and POLLPRI
actually being distinct flags and thus being mishandled in a few
corner cases. If STREAMS causes System V to have more cases (which is
possibly consistent with the old wording of the man page, and hinted
at but not documented by the caveat at the end which I removed) they
should be documented as such.

(2) Is the behavior that sockets generate POLLRDNORM on hangup (like
with select) universal or NetBSD-specific? (Or somewhere in between?)
Either way it should be documented, because in the former case it's
somewhat unexpected and in the latter it's an important portability
consideration.

(3) Is ppoll different from pollts? The man page describes it as a
wrapper, but the arguments are the same and I thought they were the
equivalent.

(4) The previous version of the man page went out of its way to note
that you can't get POLLHUP and POLLWRNORM back together, and I kept
that in the new version, but what about POLLWRBAND or other I/O flags?
ISTM that a hung-up file should not select for any kind of read or
write, or return anything else either.

(5) We should document what you're supposed to do in response to
receiving POLLERR, since it's not obvious, nor is it obvious what is
safe to do at that point without blocking, but because none of this is
obvious I have no idea what to write.

(6) The "more useful" behavior described in COMPATIBILITY is...
NetBSD-specific? Shared with FreeBSD? Universal except for legacy SVR4
clones? This should be documented.

(7) It's nice to say that ppoll() appeared in NetBSD 10, but since
it's from Linux we should say which Linux version it first appeared
in.

>How-To-Repeat:
	n/a
>Fix:

Answer the questions here and I'll update the man page :-)