On Thu, 7 May 2009, Linus Torvalds wrote: > On Thu, 7 May 2009, Miklos Szeredi wrote: > > > > One more generalization would be to allow splice to work on two > > non-pipes, using an internal intermediate pipe, a-la do_splice_direct(). > > You can't do that without some painful issues. > > Or rather, you can only do it trivially for the one case where we > _already_ do that, namely "sendfile()". That's exactly what sendfile() is > now. Hmm yeah, almost exactly: sendfile doesn't have a "destination offset" argument. > That said, maybe we could allow it in a few more cases. Or maybe people > think the simplification in user interfaces is worth making the IO be > non-interruptible (but still killable, for example, at which point the > buffered data really is dropped - but that's not different from having > the buffers in user space, so at that point it's ok). That's a hard decision. I think it's better to leave it in its current form. That means more complexity in the apps, but less unexpected nastiness from being non-interruptible. One more interesting use of splice() would be for things like speeding up "cp" on network filesystems and similarly for fs which can refcount/COW data blocks. Seems like BTRFS already has an ioctl for this, wouldn't it be nice to do it with splice()? Thanks, Miklos -- 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
