On 11.11.19 11:57, Kevin Wolf wrote: > Am 25.10.2019 um 18:04 hat Stefan Hajnoczi geschrieben: >> From: Aarushi Mehta >> >> Signed-off-by: Aarushi Mehta >> Reviewed-by: Maxim Levitsky >> Signed-off-by: Stefan Hajnoczi >> --- >> include/block/block.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/block/block.h b/include/block/block.h >> index 89606bd9f8..bdb48dcd1b 100644 >> --- a/include/block/block.h >> +++ b/include/block/block.h >> @@ -126,6 +126,7 @@ typedef struct HDGeometry { >> ignoring the format layer */ >> #define BDRV_O_NO_IO 0x10000 /* don't initialize for I/O */ >> #define BDRV_O_AUTO_RDONLY 0x20000 /* degrade to read-only if opening read-write fails */ >> +#define BDRV_O_IO_URING 0x40000 /* use io_uring instead of the thread pool */ > > Why do we need a new (global!) flag rather than a driver-specific option > for file-posix? This looks wrong to me, the flag has no sensible meaning > for any other driver. > > (Yes, BDRV_O_NATIVE_AIO is wrong, too, but compatibility means we can't > remove it easily.) To add to that, Kevin and me had a short talk on IRC, and it seemed like the reason would be that it’s easier to use this way than an option would be. To me, the problem seems to be that it’s only easier to use because of the option inheritance we have in the block layer (so you can set this flag on a qcow2 node and its file node will have it, too). But naturally this inheritance is a bit of magic (because qemu has to guess where you probably want the flag to end up), so I’d too rather avoid adding to it. OTOH, I wonder whether ease of use is really that important here. Would people who want to use io_uring really care about a command line that’s going to be a bit more complicated than just -drive file=foo.img,format=$imgfmt,aio=io_uring,if=$interface? (Namely file.aio in this case, or maybe even a full-on block graph definition.) Max