On Wed, Jun 23, 2021 at 07:45:59PM +0000, Al Viro wrote: > On Wed, Jun 23, 2021 at 10:49:51AM -0700, Omar Sandoval wrote: > > > > Fair summary. The only other thing that I'd add is this is an IO > > > interface that requires issuing physical IO. So if someone wants > > > high throughput for encoded IO, we really need AIO and/or io_uring > > > support, and we get that for free if we use readv2/writev2 > > > interfaces. > > > > > > Yes, it could be an ioctl() interface, but I think that this sort of > > > functionality is exactly what extensible syscalls like > > > preadv2/pwritev2 should be used for. It's a slight variant on normal > > > IO, and that's exactly what the RWF_* flags are intended to be used > > > for - allowing interesting per-IO variant behaviour without having > > > to completely re-implemnt the IO path via custom ioctls every time > > > we want slightly different functionality... > > > > Al, Linus, what do you think? Is there a path forward for this series as > > is? I'd be happy to have this functionality merged in any form, but I do > > think that this approach with preadv2/pwritev2 using iov_len is decent > > relative to the alternatives. > > IMO we might be better off with explicit ioctl - this magical mystery shite > with special meaning of the first iovec length is, IMO, more than enough > to make it a bad fit for read/write family. > > It's *not* just a "slightly different functionality" - it's very different > calling conventions. And the deeper one needs to dig into the interface > details to parse what's going on, the less it differs from ioctl() mess. > > Said that, why do you need a variable-length header on the read side, > in the first place? Suppose we add a new field representing a new type of encoding to the end of encoded_iov. On the write side, the caller might want to specify that the data is encoded in that new way, of course. But on the read side, if the data is encoded in that new way, then the kernel will want to return that. The kernel needs to know if the user's structure includes the new field (otherwise when it copies the full struct out, it will write into what the user thinks is the data instead). As I mentioned in my reply to Linus, maybe we can stick with preadv2/pwritev2, but make the struct encoded_iov structure a fixed size with some reserved space for future expansion. That makes this a lot less special: just copy a fixed size structure, then read/write the rest. And then we don't need to reinvent the rest of the preadv2/pwritev2 path for an ioctl. Between a fixed size structure and an ioctl, what would you prefer?
