On 12/18/2013 12:10 PM, Zach Brown wrote: > On Wed, Dec 18, 2013 at 04:41:26AM -0800, Christoph Hellwig wrote: >> On Wed, Sep 11, 2013 at 10:06:47AM -0700, Zach Brown wrote: >>> When I first started on this stuff I followed the lead of previous >>> work and added a new syscall for the copy operation: >>> >>> https://lkml.org/lkml/2013/5/14/618 >>> >>> Towards the end of that thread Eric Wong asked why we didn't just >>> extend splice. I immediately replied with some dumb dismissive >>> answer. Once I sat down and looked at it, though, it does make a >>> lot of sense. So good job, Eric. +10 Dummie points for me. >>> >>> Extending splice avoids all the noise of adding a new syscall and >>> naturally falls back to buffered copying as that's what the direct >>> splice path does for sendfile() today. >> Given the convolute mess that the splice code already is I'd rather >> prefer not overloading it even further. > I agree after trying to weave the copy offloading API into the splice > interface. There are also weird cases that we haven't really discussed > so far (preserving unwritten allocations between the copied files?) that > would muddy the waters even further. > > The further the APIs drift from each other, the more I'm prefering > giving copy offloading its own clean syscall. Even if the argument > types superficially match the splice() ABI. > >> We can still fall back to the splice code as a fallback if no option >> is provided as a last resort, but I think making the splice code handle >> even more totally different cases is the wrong direction. > I'm with you. I'll have another version out sometime after the US > holiday break.. say in a few weeks? That'll work for me, I'll update my NFS code once your new patches are out. Anna > > - z > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
