The linked video presentation from Josh Triplett is worth a listen, he gives a clear explanation.
The most interesting thing he said was in the Q&A after, paraphrasing: āIād like to see the kernel have exactly 2 syscalls, io_uring_setup and io_uring_submit.ā It seems like io_uring is an abstraction model of user-space/kernel interaction that is sufficiently powerful and general, which simplifies the interface and implementation of a lot of existing syscalls (like fork/exec, vfork, etc. mentioned in the talk) and affords optimization and performance opportunities (by eliminating the need for context switches and user-space memory & code in many cases) that would be difficult or impossible to get otherwise.
io_thing is similar to modern graphics APIs in a way, because the API explicitly builds and submits batches of commands - and the batching lives in user space. Previously, all the batching was in library code or (more often) an in-kernel optimization.
The linked video presentation from Josh Triplett is worth a listen, he gives a clear explanation.
The most interesting thing he said was in the Q&A after, paraphrasing: āIād like to see the kernel have exactly 2 syscalls, io_uring_setup and io_uring_submit.ā It seems like io_uring is an abstraction model of user-space/kernel interaction that is sufficiently powerful and general, which simplifies the interface and implementation of a lot of existing syscalls (like fork/exec, vfork, etc. mentioned in the talk) and affords optimization and performance opportunities (by eliminating the need for context switches and user-space memory & code in many cases) that would be difficult or impossible to get otherwise.
io_thing is similar to modern graphics APIs in a way, because the API explicitly builds and submits batches of commands - and the batching lives in user space. Previously, all the batching was in library code or (more often) an in-kernel optimization.
more
thing_uring
(if not io)iOS autocorrect HATES Linux syscalls