On May 6, 2015 11:45 AM, "Michael Kerrisk" <mtk.manpages@xxxxxxxxx> wrote: > > [CC += linux-api@xxxxxxxxxxxxxxx] > > Zach, > > Since this is a kernel-user-space API change, please CC linux-api@. > The kernel source file Documentation/SubmitChecklist notes that all > Linux kernel patches that change userspace interfaces should be CCed > to linux-api@xxxxxxxxxxxxxxx, so that the various parties who are > interested in API changes are informed. For further information, see > https://www.kernel.org/doc/man-pages/linux-api-ml.html > > Thanks, > > Michael > > > > > On Sat, Apr 11, 2015 at 12:00 AM, Zach Brown <zab@xxxxxxxxxx> wrote: > > Hello everyone! > > > > Here's my current attempt at the most basic system call interface for > > offloading copying between files. The system call and vfs function > > are relatively light wrappers around the file_operation method that > > does the heavy lifting. > > > > There was interest at LSF in getting the basic infrastructure merged > > before worrying about adding behavioural flags and more complicated > > implementations. This series only offers a refactoring of the btrfs > > clone ioctl as an example of an implementation of the file > > copy_file_range method. > > > > I've added support for copy_file_range() to xfs_io in xfsprogs and > > have the start of an xfstest that tests the system call. I'll send > > those to fstests@. > > > > So how does this look? > > > > Do we want to merge this and let the NFS and block XCOPY patches add > > their changes when they're ready? This sounds enough like splice that I'm wondering why the API isn't splice. --Andy -- 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
