On Tue, May 21, 2013 at 07:47:19PM +, Eric Wong wrote:
> Zach Brown wrote:
> > On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote:
> > > Why introduce a new syscall instead of extending sys_splice?
> >
> > Personally, I think it's ugly to have different operations use the same
> > sysc
Zach Brown wrote:
> On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote:
> > Why introduce a new syscall instead of extending sys_splice?
>
> Personally, I think it's ugly to have different operations use the same
> syscall just because their arguments match.
Fair enough. I think adding a
On 05/15/2013 04:03 PM, Zach Brown wrote:
On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote:
Why introduce a new syscall instead of extending sys_splice?
Personally, I think it's ugly to have different operations use the same
syscall just because their arguments match.
I agree with Za
On Wed, May 15, 2013 at 07:44:05PM +, Eric Wong wrote:
> Why introduce a new syscall instead of extending sys_splice?
Personally, I think it's ugly to have different operations use the same
syscall just because their arguments match.
But that preference aside, sure, if the consensus is that w
Zach Brown wrote:
> This adds a syscall and vfs entry point for clone_range which offloads
> data copying between existing files.
>
> The syscall is a thin wrapper around the vfs entry point. Its arguments
> are inspired by sys_splice().
Why introduce a new syscall instead of extending sys_spli
This adds a syscall and vfs entry point for clone_range which offloads
data copying between existing files.
The syscall is a thin wrapper around the vfs entry point. Its arguments
are inspired by sys_splice().
The behaviour of the vfs helper is derived from the current btrfs
CLONE_RANGE ioctl.
-
6 matches
Mail list logo