Messages in this thread | | | From | David Laight <> | Subject | RE: [RFC] situation with csum_and_copy_... API | Date | Fri, 21 Nov 2014 17:42:55 +0000 |
| |
From: Al Viro ... > We would be better off with iov_iter passed to __sock_{send,recv}msg() (as > a part of struct msghdr, instead of ->msg_iov/->msg_iovlen) and always > advanced to match the amount of data actually picked from it. With iovec > behind it remaining constant. That would work just as well as the current > variant for sendmsg(2)/recvmsg(2)/etc., be a lot more convenient for > kernel_{send,recv}msg() callers and would allow a lot of other fun stuff.
Callers of kernel_send/recvmsg() could easily be using a wrapper function that creates the 'msghdr'. When the want to send the remaining part of a buffer the old iterator will no longer be available - just the original iov and the required offset.
So it would be useful if the iterator could be initialised to a byte offset down the iov[].
Are there any current code paths where the iov[] is modified but ends up being something other than 'the remaining data'? If not then code can check whether iov[0].len has changed, and skip the 'advance' is it has.
(I've an out-of-tree driver that assumes the iov[] isn't changed.)
David
| |