polyphony 1.0 → 1.0.2

data/vendor/liburing/man/io_uring_prep_timeout_update.3

@@ -1,98 +0,0 @@
-.\" Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_prep_poll_timeout_update 3 "March 12, 2022" "liburing-2.2" "liburing Manual"
-.SH NAME
-io_uring_prep_timeoute_update \- prepare a request to update an existing timeout
-.SH SYNOPSIS
-.nf
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_prep_timeout_update(struct io_uring_sqe *" sqe ","
-.BI "                                  struct __kernel_timespec *" ts ","
-.BI "                                  __u64 " user_data ","
-.BI "                                  unsigned " flags ");"
-.PP
-.BI "void io_uring_prep_timeout_remove(struct io_uring_sqe *" sqe ","
-.BI "                                  __u64 " user_data ","
-.BI "                                  unsigned " flags ");"
-.fi
-.SH DESCRIPTION
-.PP
-These functions modify or cancel an existing timeout request. The submission
-queue entry
-.I sqe
-is setup to arm a timeout update or removal specified by
-.I user_data
-and with modifier flags given by
-.IR flags .
-Additionally, the update request includes a
-.I ts
-structure, which contains new timeout information.
-
-For an update request, the
-.I flags
-member may contain a bitmask of the following values:
-.TP
-.B IORING_TIMEOUT_ABS
-The value specified in
-.I ts
-is an absolute value rather than a relative one.
-.TP
-.B IORING_TIMEOUT_BOOTTIME
-The boottime clock source should be used.
-.TP
-.B IORING_TIMEOUT_REALTIME
-The realtime clock source should be used.
-.TP
-.B IORING_TIMEOUT_ETIME_SUCCESS
-Consider an expired timeout a success in terms of the posted completion.
-Normally a timeout that triggers would return in a
-.B -ETIME
-CQE
-.I res
-value.
-.PP
-
-.SH RETURN VALUE
-None
-.SH ERRORS
-These are the errors that are reported in the CQE
-.I res
-field. On success,
-.B 0
-is returned.
-.TP
-.B -ENOENT
-The timeout identified by
-.I user_data
-could not be found. It may be invalid, or triggered before the update or
-removal request was processed.
-.TP
-.B -EALREADY
-The timeout identified by
-.I user_data
-is already firing and cannot be canceled.
-.TP
-.B -EINVAL
-One of the fields set in the SQE was invalid. For example, two clocksources
-where given, or the specified timeout seconds or nanoseconds where < 0.
-.TP
-.B -EFAULT
-io_uring was unable to access the data specified by
-.IR ts .
-.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),
-.BR io_uring_submit (3),
-.BR io_uring_prep_timeout (3)

data/vendor/liburing/man/io_uring_prep_unlink.3

@@ -1 +0,0 @@
-io_uring_prep_unlinkat.3

data/vendor/liburing/man/io_uring_prep_unlinkat.3

@@ -1,82 +0,0 @@
-.\" Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_prep_unlinkat 3 "March 13, 2022" "liburing-2.2" "liburing Manual"
-.SH NAME
-io_uring_prep_unlinkat \- prepare an unlinkat request
-.SH SYNOPSIS
-.nf
-.B #include <fcntl.h>
-.B #include <unistd.h>
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_prep_unlinkat(struct io_uring_sqe *" sqe ","
-.BI "                            int " dirfd ","
-.BI "                            const char *" path ","
-.BI "                            int " flags ");"
-.PP
-.BI "void io_uring_prep_unlink(struct io_uring_sqe *" sqe ","
-.BI "                          const char *" path ","
-.BI "                          int " flags ");"
-.fi
-.SH DESCRIPTION
-.PP
-The
-.BR io_uring_prep_unlinkat (3)
-function prepares an unlinkat request. The submission queue entry
-.I sqe
-is setup to use the directory file descriptor pointed to by
-.I dirfd
-to start an unlinkat operation on the path identified by
-.I path
-and using the flags given in
-.IR flags .
-
-The
-.BR io_uring_prep_unlink (3)
-function prepares an unlink request. The submission queue entry
-.I sqe
-is setup to start an unlinkat operation on the path identified by
-.I path
-relative to the current working directory and using the flags given in
-.IR flags .
-
-These functions prepare an async
-.BR unlinkat (2)
-or
-.BR unlink (2)
-request. See those man pages for details.
-
-.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
-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_submit (3),
-.BR unlinkat (2),
-.BR unlink (2)

data/vendor/liburing/man/io_uring_prep_write.3

@@ -1,67 +0,0 @@
-.\" Copyright (C) 2021 Stefan Roesch <shr@fb.com>
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_prep_write 3 "November 15, 2021" "liburing-2.1" "liburing Manual"
-.SH NAME
-io_uring_prep_write \- prepare I/O write request
-.SH SYNOPSIS
-.nf
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_prep_write(struct io_uring_sqe *" sqe ","
-.BI "                         int " fd ","
-.BI "                         const void *" buf ","
-.BI "                         unsigned " nbytes ","
-.BI "                         __u64 " offset ");"
-.fi
-.SH DESCRIPTION
-.PP
-The
-.BR io_uring_prep_write (3)
-prepares an IO write request. The submission queue entry
-.I sqe
-is setup to use the file descriptor
-.I fd
-to start writing
-.I nbytes
-from the buffer
-.I buf
-at the specified
-.IR offset .
-
-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 must be 0 or -1.
-
-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 SEE ALSO
-.BR io_uring_get_sqe (3),
-.BR io_uring_submit (3)

data/vendor/liburing/man/io_uring_prep_write_fixed.3

@@ -1,72 +0,0 @@
-.\" Copyright (C) 2022 Jens Axboe <axboe@kernel.dk>
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_prep_write 3 "February 13, 2022" "liburing-2.1" "liburing Manual"
-.SH NAME
-io_uring_prep_write_fixed \- prepare I/O write request with registered buffer
-.SH SYNOPSIS
-.nf
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_prep_write_fixed(struct io_uring_sqe *" sqe ","
-.BI "                        int " fd ",
-.BI "                        const void *" buf ","
-.BI "                        unsigned " nbytes ","
-.BI "                        __u64 " offset ","
-.BI "                        int " buf_index ");"
-.fi
-.SH DESCRIPTION
-.PP
-The
-.BR io_uring_prep_write_fixed (3)
-prepares an IO write request with a previously registered IO buffer. The
-submission queue entry
-.I sqe
-is setup to use the file descriptor
-.I fd
-to start writing
-.I nbytes
-from the buffer
-.I buf
-at the specified
-.I offset
-and with the buffer matching the registered index of
-.IR buf_index .
-
-This works just like
-.BR io_uring_prep_write (3)
-except it requires the use of buffers that have been registered with
-.BR io_uring_register_buffers (3).
-The
-.I buf
-and
-.I nbytes
-arguments must fall within a region specified by
-.I buf_index
-in the previously registered buffer. The buffer need not be aligned with
-the start of the registered buffer.
-
-After the read 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 SEE ALSO
-.BR io_uring_prep_write (3),
-.BR io_uring_register_buffers (3)

data/vendor/liburing/man/io_uring_prep_writev.3

@@ -1,85 +0,0 @@
-.\" Copyright (C) 2021 Stefan Roesch <shr@fb.com>
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_prep_writev 3 "November 15, 2021" "liburing-2.1" "liburing Manual"
-.SH NAME
-io_uring_prep_writev \- prepare vector I/O write request
-.SH SYNOPSIS
-.nf
-.B #include <sys/uio.h>
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_prep_writev(struct io_uring_sqe *" sqe ","
-.BI "                          int " fd ","
-.BI "                          const struct iovec *" iovecs ","
-.BI "                          unsigned " nr_vecs ","
-.BI "                          __u64 " offset ");"
-.fi
-.SH DESCRIPTION
-.PP
-The
-.BR io_uring_prep_writev (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 .
-
-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 must be 0 or -1.
-
-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 one 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_writev2 (3),
-.BR io_uring_submit (3)

data/vendor/liburing/man/io_uring_prep_writev2.3

@@ -1,111 +0,0 @@
-.\" 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 must be 0 or -1.
-
-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 one 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)

data/vendor/liburing/man/io_uring_queue_exit.3

@@ -1,26 +0,0 @@
-.\" Copyright (C) 2020 Jens Axboe <axboe@kernel.dk>
-.\" Copyright (C) 2020 Red Hat, Inc.
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_queue_exit 3 "July 10, 2020" "liburing-0.7" "liburing Manual"
-.SH NAME
-io_uring_queue_exit \- tear down io_uring submission and completion queues
-.SH SYNOPSIS
-.nf
-.B #include <liburing.h>
-.PP
-.BI "void io_uring_queue_exit(struct io_uring *" ring ");"
-.fi
-.SH DESCRIPTION
-.PP
-.BR io_uring_queue_exit (3)
-will release all resources acquired and initialized by
-.BR io_uring_queue_init (3).
-It first unmaps the memory shared between the application and the kernel and then closes the io_uring file descriptor.
-.SH RETURN VALUE
-None
-.SH SEE ALSO
-.BR io_uring_setup (2),
-.BR mmap (2),
-.BR io_uring_queue_init (3)

data/vendor/liburing/man/io_uring_queue_init.3

@@ -1,89 +0,0 @@
-.\" Copyright (C) 2020 Jens Axboe <axboe@kernel.dk>
-.\" Copyright (C) 2020 Red Hat, Inc.
-.\"
-.\" SPDX-License-Identifier: LGPL-2.0-or-later
-.\"
-.TH io_uring_queue_init 3 "July 10, 2020" "liburing-0.7" "liburing Manual"
-.SH NAME
-io_uring_queue_init \- setup io_uring submission and completion queues
-.SH SYNOPSIS
-.nf
-.B #include <liburing.h>
-.PP
-.BI "int io_uring_queue_init(unsigned " entries ","
-.BI "                        struct io_uring *" ring ","
-.BI "                        unsigned " flags ");"
-.PP
-.BI "int io_uring_queue_init_params(unsigned " entries ","
-.BI "                               struct io_uring *" ring ","
-.BI "                               struct io_uring_params *" params ");"
-.fi
-.SH DESCRIPTION
-.PP
-The
-.BR io_uring_queue_init (3)
-function executes the
-.BR io_uring_setup (2)
-system call to initialize the submission and completion queues in the kernel
-with at least
-.I entries
-entries in the submission queue and then maps the resulting file descriptor to
-memory shared between the application and the kernel.
-
-By default, the CQ ring will have twice the number of entries as specified by
-.I entries
-for the SQ ring. This is adequate for regular file or storage workloads, but
-may be too small networked workloads. The SQ ring entries do not impose a limit
-on the number of in-flight requests that the ring can support, it merely limits
-the number that can be submitted to the kernel in one go (batch). if the CQ
-ring overflows, e.g. more entries are generated than fits in the ring before the
-application can reap them, then the ring enters a CQ ring overflow state. This
-is indicated by
-.B IORING_SQ_CQ_OVERFLOW
-being set in the SQ ring flags. Unless the kernel runs out of available memory,
-entries are not dropped, but it is a much slower completion path and will slow
-down request processing. For that reason it should be avoided and the CQ
-ring sized appropriately for the workload. Setting
-.I cq_entries
-in
-.I struct io_uring_params
-will tell the kernel to allocate this many entries for the CQ ring, independent
-of the SQ ring size in given in
-.IR entries .
-If the value isn't a power of 2, it will be rounded up to the nearest power of
-2.
-
-On success,
-.BR io_uring_queue_init (3)
-returns 0 and
-.I ring
-will point to the shared memory containing the io_uring queues. On failure
-.BR -errno
-is returned.
-
-.I flags
-will be passed through to the io_uring_setup syscall (see
-.BR io_uring_setup (2)).
-
-If the
-.BR io_uring_queue_init_params (3)
-variant is used, then the parameters indicated by
-.I params
-will be passed straight through to the
-.BR io_uring_setup (2)
-system call.
-
-On success, the resources held by
-.I ring
-should be released via a corresponding call to
-.BR io_uring_queue_exit (3).
-.SH RETURN VALUE
-.BR io_uring_queue_init (3)
-returns 0 on success and
-.BR -errno
-on failure.
-.SH SEE ALSO
-.BR io_uring_setup (2),
-.BR io_uring_register_ring_fd (3),
-.BR mmap (2),
-.BR io_uring_queue_exit (3)

data/vendor/liburing/man/io_uring_queue_init_params.3

@@ -1 +0,0 @@
-io_uring_queue_init.3

data/vendor/liburing/man/io_uring_recvmsg_cmsg_firsthdr.3

@@ -1 +0,0 @@
-io_uring_recvmsg_out.3

data/vendor/liburing/man/io_uring_recvmsg_cmsg_nexthdr.3

@@ -1 +0,0 @@
-io_uring_recvmsg_out.3

data/vendor/liburing/man/io_uring_recvmsg_name.3

@@ -1 +0,0 @@
-io_uring_recvmsg_out.3