On 12/27/18 6:55 AM, Christoph Hellwig wrote: > On Fri, Dec 21, 2018 at 12:22:21PM -0700, Jens Axboe wrote: >> This is just like io_setup(), except add a flags argument to let the >> caller control/define some of the io_context behavior. >> >> Outside of the flags, we add two user pointers for future use. >> >> Reviewed-by: Christoph Hellwig <hch@xxxxxx> > > Hmm, I don't think think I was fine with the current version.. https://marc.info/?l=linux-fsdevel&m=154539128525404&w=2 >> +/* sys_io_setup2: >> + * Like sys_io_setup(), except that it takes a set of flags >> + * (IOCTX_FLAG_*), and some pointers to user structures: >> + * >> + * *user1 - reserved for future use >> + * >> + * *user2 - reserved for future use. >> + */ >> +SYSCALL_DEFINE5(io_setup2, u32, nr_events, u32, flags, void __user *, user1, >> + void __user *, user2, aio_context_t __user *, ctxp) > > Most importantly I'm really worried about these new user1 and user2 > fields, which aren't really used for aio poll. They are used for > the I/O ring, which while I think is a really great concept, I am also > worried about overlaying into the aio interface just creating confusion.. As I said before, I don't want to create something entirely new just for the sake of it. We end up reusing basically all aio data structures and code paths, of course with some deviations here and there. I don't see why it would cause confusion. Existing aio users are going to be using io_setup(2) and nothing changes on that front. If you want polled aio without using the ring, you can do so with io_setup2(2). The fact that the ring addition ends up being setup in the same fashion doesn't seem problematic to me. For the polled part, 99% of the code ends up being the same. -- Jens Axboe
