lkml.org 
[lkml]   [2006]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] splice support #2
Date
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/

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