On 2/1/20 5:53 AM, Andres Freund wrote: > 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? Not sure what I'm missing here, but liburing already has __sys_io_uring_enter() for this purpose, and ditto for the register and setup functions? -- Jens Axboe
