lkml.org 
[lkml]   [2006]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-03-31 04:37    [W:0.085 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site