Messages in this thread | | | From | Bodo Eggert <> | Subject | Re: [PATCH] splice support #2 | Date | Mon, 03 Apr 2006 14:39:16 +0200 |
| |
Pavel Machek <pavel@suse.cz> wrote:
>> We should extend the userspace API so that it is prepared to receive >> 'excess data' via a separate 'flush excess data to' file descriptor: >> >> sys_splice(fd_in, fd_out, fd_flush, size, >> max_flush_size, *bytes_flushed) > > I still see problems with error handling here. You get -EIO to > userspace. How do you know if it is error reading fd_in, or error > writing fd_out?
ACK.
Possibly you'll get an error reading from fd_in while also getting an error flushing the data to fd_out, and an additional error while trying to rescue the data on fd_flush.
Additionally you'll want to know the amount of transfered bytes even in case of an error.
struct splice_fds { int in_fd, int in_errno, int out_fd, int out_errno,
/* used on transfer error to rescue the to-be-flushed data: */ int err_fd, int err_errno, /* err_fd == -1 -> don't use */ int err_size /* in: max. size, out: used size, unchanged if no error */ } int sys_splice(struct splice_fds *fds, size, flags) /* returns transfered_bytes even in case of an error */
Possible flags: - Streaming, copied data won't be used too soon. - Unconditionally use err_fd as a buffer, e.g. because we know that seeking from in_fd to out_fd is slow while err_fd is mapped memory. - fail if err_fd == -1 and an error could cause data loss (out_fd must have a buffer like a pipe)
Dangers: splice(in_fd = /dev/zero, out_fd = /dev/null, ...) ...
</brainstorming> -- Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF verbreiteten Lügen zu sabotieren. - 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/
| |