Re: [PATCH 0/5] splice: locking changes and code refactoring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 18, 2014 at 07:46:49AM +0000, Al Viro wrote:

> Um...
> int pipe_to_file(struct pipe_inode_info *pipe, struct pipe_buffer *buf,
>                  struct splice_desc *sd)
> ...
>         if (buf->page != page) {
>                 char *src = buf->ops->map(pipe, buf, 1);
>                 char *dst = kmap_atomic(page);
> 
>                 memcpy(dst + offset, src + buf->offset, this_len);
>                 flush_dcache_page(page);
>                 kunmap_atomic(dst);
>                 buf->ops->unmap(pipe, buf, src);
> 	}

BTW, that if (buf->page != page) is always true - it's a leftover from
before Nick's removal of ->steal() uses in pipe_to_file() (as well as
the big fat comment in front of that function that had lost any relation
to what it's doing 7 years ago)...

Is there anybody maintaining fs/splice.c these days?  I'd been doing
massive RTFS in that area lately, but it would certainly be nice to
have some braindump on the design and issues in that thing, preferably
still matching the code...
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux