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?
