On 10/4/19 10:03 AM, Jeff Moyer wrote: > Jens Axboe <axboe@xxxxxxxxx> writes: > >> On 10/4/19 9:34 AM, Jeff Moyer wrote: >>> If I'm reading this (and the code) right, that means you can't add files >>> to a set. Wouldn't that be a useful thing to do, instead of just >>> replacing existing ones? >> >> You can add files to a set, you just can't grow a set beyond the size >> you originally registered. I actually forgot to post the pre-patch for >> this, which is: >> >> http://git.kernel.dk/cgit/linux-block/commit/?h=for-5.5/io_uring&id=fb3e60f87aa43f4f047f01243d6be54dadd9d67a >> >> This allows registering -1 as the fd, so you could register 10 files, >> but an array of size 500 (for example), and the last 490 fds are just >> -1. Then you can use the IORING_REGISTER_FILES_UPDATE to replace those >> empty fds with real files later on. > > That makes more sense, but still requires a priori knowledge of how many > files you'll need to work with, otherwise you're back to > unregister/register dance. Is it really that hard to grow on demand? It's not, it's just more efficient to add a file through replace, than it is to alloc a new array, copy things over, free it. That also impacts the application side of things, since that has to maintain an array of descriptors so that it knows what fd maps to what index. If you expose growing, you also have some kind of obligation to make it efficient, and I just don't think that's possible. But there's nothing preventing this API from supporting it, you'd just do an update with offset == current_array_size, and then nr_args as what to grow with. Currently that would -EINVAL, but it could be added as a feature. -- Jens Axboe
