1 files changed, 111 insertions, 0 deletions
diff --git a/man/io_uring_prep_writev2.3 b/man/io_uring_prep_writev2.3
new file mode 100644
index 0000000..5093596
--- /dev/null
+++ b/man/io_uring_prep_writev2.3
@@ -0,0 +1,111 @@
+.\" Copyright (C) 2021 Stefan Roesch <shr@fb.com>
+.\"
+.\" SPDX-License-Identifier: LGPL-2.0-or-later
+.\"
+.TH io_uring_prep_writev2 3 "November 15, 2021" "liburing-2.1" "liburing Manual"
+.SH NAME
+io_uring_prep_writev2 \- prepare vector I/O write request with flags
+.SH SYNOPSIS
+.nf
+.B #include <sys/uio.h>
+.B #include <liburing.h>
+.PP
+.BI "void io_uring_prep_writev2(struct io_uring_sqe *" sqe ","
+.BI "                           int " fd ","
+.BI "                           const struct iovec *" iovecs ","
+.BI "                           unsigned " nr_vecs ","
+.BI "                           __u64 " offset ","
+.BI "                           int " flags ");"
+.fi
+.SH DESCRIPTION
+.PP
+The
+.BR io_uring_prep_writev2 (3)
+prepares a vectored IO write request. The submission queue entry
+.I sqe
+is setup to use the file descriptor
+.I fd
+to start writing
+.I nr_vecs
+from the
+.I iovecs
+array at the specified
+.IR offset .
+The behavior of the function can be controlled with the
+.I flags
+parameter.
+
+Supported values for
+.I flags
+are:
+.TP
+.B RWF_HIPRI
+High priority request, poll if possible
+.TP
+.B RWF_DSYNC
+per-IO O_DSYNC
+.TP
+.B RWF_SYNC
+per-IO O_SYNC
+.TP
+.B RWF_NOWAIT
+per-IO, return
+.B -EAGAIN
+if operation would block
+.TP
+.B RWF_APPEND
+per-IO O_APPEND
+
+.P
+On files that support seeking, if the offset is set to
+.BR -1 ,
+the write operation commences at the file offset, and the file offset is
+incremented by the number of bytes written. See
+.BR write (2)
+for more details. Note that for an async API, reading and updating the
+current file offset may result in unpredictable behavior, unless access
+to the file is serialized. It is not encouraged to use this feature if it's
+possible to provide the desired IO offset from the application or library.
+
+On files that are not capable of seeking, the offset is ignored.
+
+After the write has been prepared, it can be submitted with one of the submit
+functions.
+
+.SH RETURN VALUE
+None
+.SH ERRORS
+The CQE
+.I res
+field will contain the result of the operation. See the related man page for
+details on possible values. Note that where synchronous system calls will return
+.B -1
+on failure and set
+.I errno
+to the actual error value, io_uring never uses
+.IR errno .
+Instead it returns the negated
+.I errno
+directly in the CQE
+.I res
+field.
+.SH NOTES
+Unless an application explicitly needs to pass in more than iovec, it is more
+efficient to use
+.BR io_uring_prep_write (3)
+rather than this function, as no state has to be maintained for a
+non-vectored IO request.
+As with any request that passes in data in a struct, that data must remain
+valid until the request has been successfully submitted. It need not remain
+valid until completion. Once a request has been submitted, the in-kernel
+state is stable. Very early kernels (5.4 and earlier) required state to be
+stable until the completion occurred. Applications can test for this
+behavior by inspecting the
+.B IORING_FEAT_SUBMIT_STABLE
+flag passed back from
+.BR io_uring_queue_init_params (3).
+.SH SEE ALSO
+.BR io_uring_get_sqe (3),
+.BR io_uring_prep_write (3),
+.BR io_uring_prep_writev (3),
+.BR io_uring_submit (3)