That's right.

Moreover, for a large number of traditional Linux syscalls (including the many variants of read/write/send/recv) there are now better alternatives that are invoked as subcommands of a single syscall: io_uring_enter.

▲

ReDress 7 hours ago | parent [-]

io-uring is great for this.

However, I am bit skeptical as to whether io-uring will ever support all Linux syscalls.

At this point I am convinced that io-uring primarily supports I/O API / syscalls. That would mean syscalls relating to disk and network I/O. While this covers a lot of syscalls it most definitely doesn't cover all.

Though, to give some credit her, it does also cover to syscalls relating to kernel features like futex but yeah, for the most part it doesn't cover much that doesn't have to do with I/O.

Which is obviously not a problem but raises the question of whether it ever will support other kernel features.

	▲	adrian_b 3 hours ago \| parent [-]
		The io_uring interface is preferable to classic syscalls for any kind of syscall that requires the kernel to perform a significant amount of work or to wait for some external events, so a long time could pass until the completion of the work or until the occurrence of the external events, and possibly for some auxiliary syscalls that modify settings relevant to the previous syscalls. Many of the most important syscalls belong to this class, but most of them already have io_uring alternatives. Many other syscalls are not of this kind, so for them there is no reason to replace the traditional syscall interface. For the syscalls appropriate for io_uring the essential characteristic is that their completions can occur in a different order than the submissions of their requests, which is why all previous methods of handling them were inefficient, because they required the user program to waste time with superfluous activities, instead of just picking the completion messages from a queue. Where this out-of-order execution is not needed, invoking the syscalls in the same way as you invoke any user function is fine. The initial implementation of io_uring lacked the alternatives for many important syscalls, but since then most of the holes have been filled. Besides more obvious syscalls of the read/write type, which are used for files accessed in the classic way, in order to reach maximum performance with memory-mapped files the old "madvise" syscall must be replaced with IORING_OP_MADVISE, used with Linux-specific advices (MADV_COLD, MADV_PAGEOUT, MADV_POPULATE_READ, MADV_POPULATE_WRITE).