Re: New copyfile system call - discuss before LSF?

[Pavel Machek <pavel@ucw.cz>]

Hi!

> > > If I'm guessing correctly, sendfile64()+flags would be annoying because it's
> > > missing an out_fd_offset.  The host will want to offload the guest's copies by
> > > calling sendfile on block ranges of a guest disk image file that correspond to
> > > the mappings of the in and out files in the guest.
> > > 
> > > You could make it work with some locking and out_fd seeking to set the
> > > write offset before calling sendfile64()+flags, but ugh.
> > > 
> > >  ssize_t sendfile(int out_fd, int in_fd, off_t in_offset, off_t
> > >                   out_offset, size_t count, int flags);
> > > 
> > > That seems closer.
> > 
> > psendfile() ?
> > 
> > I fully agree that sounds reasonable... Just being an ass. :-)
> 
> splice() already has offset for both fds and a flags arg:
> 
>        ssize_t splice(int fd_in, loff_t *off_in, int fd_out,
>                       loff_t *off_out, size_t len, unsigned int flags);
> 
> The current downside is it requires one fd to be a pipe, so it's
> just not very easy to use from my perspective[1].
...
> [1] my splice() annoyances:
>     * need to create/manage a pipe
>     * copy size limited by pipe size
>     * doesn't reduce userspace syscalls (just data copy overhead)
>     * easy to misuse and starve with blocking sockets + big buffers
>     * not many users, so bugs creep in (v3.7.8 was the first usable
>       version of the 3.7 series for TCP sockets)

Could library be created to make it less annoying to use, and harder
to misuse?

splice man page does not mention pipe size limit... 
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html