- Avoid double use of "request" in a single sentence.  Instead, describe
  aio_sigevent as being used to request notification of the associated
  operation's completion.  This matches the language used to describe
  aio_sigevent in aio(4).
- Simplify the prohibition on modifying buffers while requests are in
  flight.
- Fix case mismatch.
- Drop note about not using stack variables. C programmers should be able
  to figure out if a stack variable is safe based on the later warning
  about the life cycle requirements of control blocks.
- Remove prohibition on modifying the I/O buffer for aio_fsync() since
  it does not use an I/O buffer.  For aio_mlock(), prohibit modifications
  to the mapping (e.g. due to mprotect, munmap, mmap, etc.) but do not
  prohibit modifications to the memory backing the buffer (stores into
  the pages backing the buffer).

The asynchronous I/O changes made previously result in different
behavior out of the box. Previously all AIO requests failed with
ENOSYS / SIGSYS unless aio.ko was explicitly loaded. Now, some AIO
requests complete and others ("unsafe" requests) fail with EOPNOTSUPP.

Reword the introductory paragraph in aio(4) to add a general
description of AIO before describing the vfs.aio.enable_unsafe sysctl.

Remove the ENOSYS error description from aio_fsync(2), aio_read(2),
and aio_write(2) and replace it with a description of EOPNOTSUPP.

Remove the ENOSYS error description from aio_mlock(2).

Log a message to the system log the first time a process requests an
"unsafe" AIO request that fails with EOPNOTSUPP. This is modeled on
the log message used for processes using the legacy pty devices.

Approved by:	re (gjb)

- Add a sigevent(3) manpage to give a general overview of the sigevent
  structure and the available notification mechanisms.
- Document that AIO requests contain a nested sigevent structure that can
  be used to request completion notification.
- Expand the sigevent details in other manuals to note details such as
  the extra values stored in a queued signal's information or in a posted
  kevent.

Approved by:	re (gjb)

PR:		191174
Submitted by:	Franco Fichtner  <franco at lastsummer.de>

They have no effect when coming in pairs, or before .Bl/.Bd

Submitted by: ru