On Fri, Jan 29, 2021 at 04:10:44PM +0800, Zorro Lang wrote: > On Thu, Jan 28, 2021 at 03:31:40PM -0600, Eric Sandeen wrote: > > We might have URING #defined at build time, but be running on a kernel > > which does not support it. > > > > For that reason, we should not exit with an error if > > io_uring_queue_init() fails with ENOSYS. We can just note the lack of > > support and skip all future io_uring operations. > > > > Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx> > > --- > > > > diff --git a/ltp/fsstress.c b/ltp/fsstress.c > > index 22df5e38..73751935 100644 > > --- a/ltp/fsstress.c > > +++ b/ltp/fsstress.c > > @@ -35,6 +35,7 @@ io_context_t io_ctx; > > #include <liburing.h> > > #define URING_ENTRIES 1 > > struct io_uring ring; > > +bool have_io_uring; /* to indicate runtime availability */ > > #endif > > #include <sys/syscall.h> > > #include <sys/xattr.h> > > @@ -706,9 +707,15 @@ int main(int argc, char **argv) > > } > > #endif > > #ifdef URING > > + have_io_uring = true; > > + /* If ENOSYS, just ignore uring, other errors are fatal. */ > > Yes, I thought about if we should do this since rhel8 kernel removed io_uring > support from kernel, but left userspace liburing. But if we do this for io_uring, > should we do the same check the others which can be disabled from kernel? Likes: AIO? io_uring is a relative new interface, and it's quite possible that some distros don't support it. aio has been there for a long time, and is very unlikely disabled. If we really need to do the same check for aio, we could do it in another patch I guess. Thanks, Eryu
