One of the fabled features with chains has long been the desire to support things like: <open fileX><read from fileX><close fileX> in a single chain. This currently doesn't work, since the read/close depends on what file descriptor we get on open. This is very much a RFC patchset, but it allows the read/close above to set their fd to a magic value, IOSQE_FD_LAST_OPEN. If set to this value, the file descriptor will be inherited from the last open in that chain. If there are no opens in the chain, the IO is simply errored. Only a single magic fd value is supported, so if the chain needs to operate on two of them, care needs to be taken to ensure things are correct. Consider for example the desire to open fileX and read from it, and write that to another file. You could do that ala: <open fileX><read from fileX><close fileX><open fileY><write to fileY> <close fileY> and have that work, but you cannot open both files first, then read/write and then close. I don't think that necessarily poses a problem, and I'd rather not get into fd nesting and things like that. Open to input here, of course. Another concern here is that we currently error linked IO if it doesn't match what was asked for, a prime example being short reads. For a basic chain of open/read/close, the close doesn't really care if the read is short or not. It's only if we have further links in the chain that depend on the read length that this is a problem. Anyway, with this, prep handlers can't look at ->file as it may not be valid yet. Only close and read/write do that, from a quick glance, and there are two prep patches to split that a bit (2 and 3). Patch 1 is just a basic prep patch as well, patch 4 is the functional part. I added a small 'orc' (open-read-close) test program in the fd-pass branch of liburing: https://git.kernel.dk/cgit/liburing/plain/test/orc.c?h=fd-pass as an example use case. -- Jens Axboe
