|author||Pavel Begunkov <firstname.lastname@example.org>||2022-03-17 15:23:34 +0000|
|committer||Jens Axboe <email@example.com>||2022-03-17 10:17:09 -0600|
man: clarifications about direct open/accept
Direct open/accept replaces files for slots that are taken, so it's not necessary to use sparse file tables. Update on that, mention the replacing mechanism, and add a note about possible compitability issues for raw io_uring API users. Signed-off-by: Pavel Begunkov <firstname.lastname@example.org> Link: https://email@example.com [axboe: add note on the existing entry being closed as well] Signed-off-by: Jens Axboe <firstname.lastname@example.org>
Diffstat (limited to 'man/io_uring_prep_openat2.3')
1 files changed, 11 insertions, 6 deletions
diff --git a/man/io_uring_prep_openat2.3 b/man/io_uring_prep_openat2.3
index 672fd7c..4898e30 100644
@@ -55,13 +55,18 @@ field should use the direct descriptor value rather than the regular file
descriptor. Direct descriptors are managed like registered files.
If the direct variant is used, the application must first have registered
-a sparse file table using
+a file table using
.BR io_uring_register_files (3)
-of the appropriate size. A sparse table is one where each element is first
-registered with a value of
-Once registered, a direct open request may use any sparse entry in that
-table, as long as it is within the size of the registered table.
+of the appropriate size. Once registered, a direct accept request may use any
+entry in that table, as long as it is within the size of the registered table.
+If a specified entry already contains a file, the file will first be removed
+from the table and closed. It's consistent with the behavior of updating an
+existing file with
+.BR io_uring_register_files_update (3).
+Note that old kernels don't check the SQE
+field, which is not a problem for liburing helpers, but users of the raw
+io_uring interface need to zero SQEs to avoid unexpected behavior.
This function prepares an async
.BR openat2 (2)