Messages in this thread | | | Date | Fri, 31 Mar 2006 10:59:33 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] splice support #2 |
| |
Linus Torvalds wrote:
> splice() really can handle any fd->fd move. > > The reason you want to have a pipe in the middle is that you have to > handle partial moves _some_ way. And the pipe being the buffer really does > allow that, and also handles the case of "what happens when we received > more data than we could write". > > So the way to do copies is > > int pipefd[2]; > unsigned long copied = 0; > > if (pipe(pipefd) < 0) > error > > for (;;) { > int nr = splice(in, pipefd[1], MAX_INT, 0); > if (nr <= 0) > break; > do { > int ret = splice(pipefd[0], out, nr, 0); > if (ret <= 0) { > error: couldn't write 'nr' bytes > break; > } > > nr -= ret; > } while (nr); > } > close(pipefd[0]); > close(pipefd[1]); >
I think it makes sense to have a 64-bit length. It just seems cleaner because it is in userspace units of file offset. Also, might you be able to do a single file-sized file<->file splice, and have it do a remote copy on a suitable network fs, or a whole-file COW on some local fs (maybe not, as splice doesn't deal with metadata... I don't know the tricky details of fses).
But your argument against a 64-bit length seemed to involve limiting the usage that sys_splice would see. Make it 64-bit instead and someone might come up with something that you hadn't thought of. Is there any downside?
No offsets :( Don't they only increase flexibility? Or would you prefer to add a new sys_psplice for that?
-- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |