Hi, As long as the syscalls aren't exposed by glibc it'd be useful - at least for me - to have liburing expose the syscalls without really going through liburing facilities... Right now I'm e.g. using a "raw" io_uring_enter(IORING_ENTER_GETEVENTS) to be able to have multiple processes safely wait for events on the same uring, without needing to hold the lock [1] protecting the ring [2]. It's probably a good idea to add a liburing function to be able to do so, but I'd guess there are going to continue to be cases like that. In a bit of time it seems likely that at least open source users of uring that are included in databases, have to work against multiple versions of liburing (as usually embedding libs is not allowed), and sometimes that is easier if one can backfill a function or two if necessary. That syscall should probably be under a name that won't conflict with eventual glibc implementation of the syscall. Obviously I can just do the syscall() etc myself, but it seems unnecessary to have a separate copy of the ifdefs for syscall numbers etc. What do you think? [1] It's more efficient to have the kernel wake up the waiting processes directly, rather than waking up one process, which then wakes up the other processes by releasing a lock. [2] The reason one can't just use io_uring_submit_and_wait or such, is because it's not safe to call __io_uring_flush_sq(ring) while somebody else might access the ring. Greetings, Andres Freund
