]> git.karo-electronics.de Git - karo-tx-linux.git/commit
fs: pull iov_iter use higher up the stack
authorZach Brown <zab@zabbo.net>
Fri, 14 Jun 2013 20:54:17 +0000 (15:54 -0500)
committerDave Kleikamp <dave.kleikamp@oracle.com>
Wed, 18 Sep 2013 15:16:29 +0000 (10:16 -0500)
commiteb484c26778bd6f8ba0fa276339580f004b6d231
tree182ee577f7f35495353ef6e8a7f7104c17fd7ffd
parentee6a90f4c865fb457cf66350d89faa85a4a4d50c
fs: pull iov_iter use higher up the stack

Right now only callers of generic_perform_write() pack their iovec
arguments into an iov_iter structure.  All the callers higher up in the
stack work on raw iovec arguments.

This patch introduces the use of the iov_iter abstraction higher up the
stack.  Private generic path functions are changed to operation on
iov_iter instead of on raw iovecs.  Exported interfaces that take iovecs
immediately pack their arguments into an iov_iter and call into the
shared functions.

File operation struct functions are added with iov_iter as an argument
so that callers to the generic file system functions can specify
abstract memory rather than iovec arrays only.

Almost all of this patch only transforms arguments and shouldn't change
functionality.  The buffered read path is the exception.  We add a
read_actor function which uses the iov_iter helper functions instead of
operating on each individual iovec element.  This may improve
performance as the iov_iter helper can copy multiple iovec elements from
one mapped page cache page.

As always, the direct IO path is special.  Sadly, it may still be
cleanest to have it work on the underlying memory structures directly
instead of working through the iov_iter abstraction.

Signed-off-by: Zach Brown <zab@zabbo.net>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Documentation/filesystems/Locking
Documentation/filesystems/vfs.txt
include/linux/fs.h
mm/filemap.c