On Mon, Sep 22, 2014 at 10:30:53AM -0700, Christoph Hellwig wrote: > Currently only /dev/null, fusedev and the socket code have a > splice_write implementation that isn't iter_file_splice_write, and > it seems like these three could easily be switched over if they > implemented a ->write_iter. Not really. A minor nitpick is that you've missed port_fops_splice_write(), but the real bitch isn't that and not even the sockets (see the fun with iov_iter sendmsg/recvmsg work getting resurrected). It's that NULL ->splice_write() means default_file_splice_write. IOW, you'd need either ->write_iter() for _everything_ (with support of bvec-backed ones included, since that's what iter_file_splice_write() will feed to ->write_iter()), or you need to have do_splice_from() check if ->write_iter is NULL and go for default_file_splice_write() instead of iter_file_splice_write(). The latter might be doable, but the former is really over the top - for that we'd need to touch every driver instance of ->write() out there. You want to do that, it's your funeral... > Similarly it seems to be like we could kill ->splice_read by > implementing an equivalent iteration over ->read_iter. Hard to do. I agree that we want to, but it'll take quite a bit of work on iov_iter primitives, I'm afraid. At the very least, we want a variant of iov_iter that could steal pages. Don't forget that a large part of the rationale behind splice_read was the ability to play zero-copy games. I'm not sure if it will happen this cycle; there's more than enough fun on the net/* side. _If_ that ends up done faster than I expect it to be, ->splice_read() is the obvious next target. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
