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