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. metze
Attachment:
signature.asc
Description: OpenPGP digital signature
