We don't support it, so there's no need to tell readers what would
happen if we did.  Also, don't remind the user that a certain field is
ignored by aio_read.  Mentioning every ignored field would make the man
pages too verbose.

Sponsored by:	Axcient
Reviewed by:	Pau Amma <pauamma@gundo.com>
Differential Revision: https://reviews.freebsd.org/D42622

(cherry picked from commit 18e2c4175f78f1aaa648dd7fb7530220aed23671)

Looks like a copypasta from aio_write.2.

[skip ci]

Reported by:	Paul Floyd <pjfloyd@wanadoo.fr>
Sponsored by:	Axcient
Reviewed by:	jilles (manpages)
Differential Revision: https://reviews.freebsd.org/D42621

(cherry picked from commit 04cfe6c12ccc75624dc87ab8f44c4852b16f0c4f)

Remove /^\.\\"\n\.\\"\s*\$FreeBSD\$$\n/

Similar commit in main:
(cherry picked from commit fa9896e082a1)

POSIX AIO is great, but it lacks vectored I/O functions. This commit
fixes that shortcoming by adding aio_writev and aio_readv. They aren't
part of the standard, but they're an obvious extension. They work just
like their synchronous equivalents pwritev and preadv.

It isn't yet possible to use vectored aiocbs with lio_listio, but that
could be added in the future.

Reviewed by:    jhb, kib, bcr
Relnotes:       yes
Differential Revision: https://reviews.freebsd.org/D27743

- 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).

Requested by:	wblock (1,2), kib (4)
Reviewed by:	kib, rpokala, wblock
MFC after:	3 days
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D7462

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.

Reviewed by:	kib (earlier version)
MFC after:	1 week
Sponsored by:	Chelsio Communications
Differential Revision:	https://reviews.freebsd.org/D7151

- 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.

Reviewed by:	kib
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D7122

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