On 1/16/20 3:50 PM, Stefan Metzmacher wrote: > Am 09.01.20 um 03:03 schrieb Jens Axboe: >> On 1/8/20 6:02 PM, Jens Axboe wrote: >>> On 1/8/20 4:05 PM, Stefan Metzmacher wrote: >>>> Am 08.01.20 um 23:57 schrieb Jens Axboe: >>>>> On 1/8/20 2:17 PM, Stefan Metzmacher wrote: >>>>>> Am 07.01.20 um 18:00 schrieb Jens Axboe: >>>>>>> Sending this out separately, as I rebased it on top of the work.openat2 >>>>>>> branch from Al to resolve some of the conflicts with the differences in >>>>>>> how open flags are built. >>>>>> >>>>>> Now that you rebased on top of openat2, wouldn't it be better to add >>>>>> openat2 that to io_uring instead of the old openat call? >>>>> >>>>> The IORING_OP_OPENAT already exists, so it would probably make more sense >>>>> to add IORING_OP_OPENAT2 alongside that. Or I could just change it. Don't >>>>> really feel that strongly about it, I'll probably just add openat2 and >>>>> leave openat alone, openat will just be a wrapper around openat2 anyway. >>>> >>>> Great, thanks! >>> >>> Here: >>> >>> https://git.kernel.dk/cgit/linux-block/log/?h=for-5.6/io_uring-vfs >>> >>> Not tested yet, will wire this up in liburing and write a test case >>> as well. >> >> Wrote a basic test case, and used my openbench as well. Seems to work >> fine for me. Pushed prep etc support to liburing. > > Thanks! > > Another great feature would the possibility to make use of the > generated fd in the following request. > > This is a feature that's also available in the SMB3 protocol > called compound related requests. > > The client can compound a chain with open, getinfo, read, close > getinfo, read and close get an file handle of -1 and implicitly > get the fd generated/used in the previous request. Right, the "plan" there is to utilize BPF to make this programmable. We really need something more expressive to be able to pass information between SQEs that are linked, or even to decide which link to run depending on the outcome of the parent. There's a lot of potential there! -- Jens Axboe
