]> git.karo-electronics.de Git - karo-tx-linux.git/commit
fs: pull iov_iter use higher up the stack
authorZach Brown <zab@zabbo.net>
Tue, 15 Oct 2013 18:44:35 +0000 (13:44 -0500)
committerDave Kleikamp <dave.kleikamp@oracle.com>
Tue, 15 Oct 2013 18:44:35 +0000 (13:44 -0500)
commit5c2ce19d031821d3a74fc9e949168bb568a26c08
tree71080d2d7a910958a1c35642c174a4a5733a8172
parentb009eabefe9042636099b4c80bc0de380e7d7c84
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