summaryrefslogtreecommitdiff
path: root/man/io_uring_prep_writev2.3
blob: cceae97024991621699dff95a0195bfa12eb3ca8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
.\" 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
.BR "#include <sys/uio.h>"
.BR "#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
.PP
.SH DESCRIPTION
.PP
The io_uring_prep_writev2() 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
.I 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
.B -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
.I errno.
Instead it returns the negated
.I errno
directly in the CQE
.I res
field.
.SH NOTES
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), io_uring_prep_write (3), io_uring_prep_writev (3), io_uring_submit (3)