Remove mentions of ENOSYS added in d97e44784bb5

aio(4) is a hard requirement in the kernel as of f3215338ef82. The
scenario that the patch was submitted for is no longer possible.

This isn't a stra

Remove mentions of ENOSYS added in d97e44784bb5

aio(4) is a hard requirement in the kernel as of f3215338ef82. The
scenario that the patch was submitted for is no longer possible.

This isn't a straight up revert since the previous change also addressed
some minor issues.

PR: 190942
Reported by: asomers
MFC after: 2 weeks
MFC with: d97e44784bb5
Fixes: d97e44784bb5 ("aio_*(2): mention ENOSYS under ERRORS")
Differential Revision: https://reviews.freebsd.org/D49541

show more ...

aio_*(2): mention ENOSYS under ERRORS

ENOSYS can occur if aio(4) is not loaded in the kernel. Document this
behavior so consumers on FreeBSD can better understand that this is a
possible scenario.

aio_*(2): mention ENOSYS under ERRORS

ENOSYS can occur if aio(4) is not loaded in the kernel. Document this
behavior so consumers on FreeBSD can better understand that this is a
possible scenario.

Clean up the manpages slightly while here:
- Sort `ERRORS` by errno(3).
- Use `.Fx` instead of `FreeBSD`.

MFC after: 2 weeks
Reviewed by: ziaee
PR: 190942
Differential Revision: https://reviews.freebsd.org/D49502

show more ...

libsys: relocate implementations and manpages

Remove core system call implementations and documentation to lib/libsys
and lib/libsys/<arch> from lib/libc/sys and lib/libc/<arch>/<sys>.
Update paths

libsys: relocate implementations and manpages

Remove core system call implementations and documentation to lib/libsys
and lib/libsys/<arch> from lib/libc/sys and lib/libc/<arch>/<sys>.
Update paths to allow libc to find them in their new home.

Reviewed by: kib, emaste, imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/908

show more ...

Remove _POSIX_PRIORITIZED_IO references from man pages

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
ignor

Remove _POSIX_PRIORITIZED_IO references from man pages

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.

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

show more ...

Remove $FreeBSD$: two-line nroff pattern

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

aio_fsync(2): Support O_DSYNC.

aio_fsync(O_DSYNC, ...) is the asynchronous version of fdatasync(2).

Reviewed by: kib, asomers, jhb
Differential Review: https://reviews.freebsd.org/D25071

Fix various nits in the aio operation manpages.

- Avoid double use of "request" in a single sentence. Instead, describe
aio_sigevent as being used to request notification of the associated
oper

Fix various nits in the aio operation manpages.

- 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

show more ...

Add more documentation regarding unsafe AIO requests.

The asynchronous I/O changes made previously result in different
behavior out of the box. Previously all AIO requests failed with
ENOSYS / SIGSY

Add more documentation regarding unsafe AIO requests.

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

show more ...

Add documentation for the sigevent structure.

- Add a sigevent(3) manpage to give a general overview of the sigevent
structure and the available notification mechanisms.
- Document that AIO reques

Add documentation for the sigevent structure.

- 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

show more ...

- Fix EBADF description, in following the future POSIX tc and what FreeBSD
actually implements.
- Improve grammar: use more preferred "can", not "could".

Submitted by: jilles

Provide the manual page for aio_fsync(2).

Reviewed by: davidxu
MFC after: 1 week