On Tue, Nov 04, 2014 at 03:13:55PM +0000, Al Viro wrote: > > Think of it that way: every sendmsg/recvmsg path leading to memcpy_fromiovec > and its friends (including the open-coded ones) would need to be changed > at some point. Assuming we do not end up passing struct iov_iter * as > an extra argument through a fairly large part of net/* (and that would > be prohibitively hard and messy, not to mention the effects on the stack > footprint, etc.), the most obvious strategy is to have that thing passed > where msg_iov/msg_iovlen are - in struct msghdr. *IF* we go that way, > it makes a whole lot of sense to start with a bunch of cleanups that > will make sense on their own (most of callers of skb_copy_datagram_iovec > do look like skb_copy_datagram_iovec(skb, 0, msg->msg_iov, copied); might > as well give it an inlined helper) and will reduce the amount of places > where ->msg_iov is used. With such cleanups standing on their own and > being splittable from the rest of the queue. And leaving us with fewer > places in code that deal with ->msg_iov and need to be dealt with.
I think your solution is great. However, I don't see how my four patches impede in anyway the work that you're doing. I presume your first patch will make skb_copy_datagram_msg just a wrapper around skb_copy_datagram_iovec. Since I'm not removing skb_copy_datagram_iovec (it can't be removed until all users are gone) you can still do that and when you're ready to switch over to iov_iter you can just move the wrapper over to skb_copy_datagram_iter. No? Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
