Hi Jens,
this looks very useful, thanks!
I have an additional feature request to make this even more useful...
IO_OP_ACCEPT allows a fixed descriptor for the listen socket
and then can generate a fixed descriptor for the accepted connection,
correct?
It would be extremely useful to also allow that pattern
for IO_OP_OPENAT[2], which currently is not able to get
a fixed descriptor for the dirfd argument (this also applies to
IO_OP_STATX, IO_OP_UNLINK and all others taking a dirfd).
Being able use such a sequence:
OPENTAT2(AT_FDCWD, "directory") => 1 (fixed)
STATX(1 (fixed))
FGETXATTR(1 (fixed)
OPENAT2(1 (fixed), "file") => 2 (fixed)
STATX(2 (fixed))
FGETXATTR(2 (fixed))
CLOSE(1 (fixed)
DUP( 2 (fixed)) => per-process fd for ("file")
I looked briefly how to implement that.
But set_nameidata() takes 'int dfd' to store the value
and it's used later somewhere deep down the stack.
And makes it too complex for me to create patches :-(
It would great if someone could have a look how to make this work.
Currently using direct descriptors with open or accept requires the
application to manage the descriptor space, picking which slot to use
for any given file. However, there are cases where it's useful to just
get a direct descriptor and not care about which value it is, instead
just return it like a normal open or accept would.
This will also be useful for multishot accept support, where allocated
direct descriptors are a requirement to make that feature work with
these kinds of files.
This adds support for allocating a new fixed descriptor. This is chosen
by passing in IORING_FILE_INDEX_ALLOC as the fixed slot, which is beyond
any valid value for the file_index.
I guess that would not work for linked request, as we don't know the
actual id before submitting the requests.
Thanks!
metze
