From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60895) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8a0n-0002A9-DG for qemu-devel@nongnu.org; Fri, 16 Mar 2012 12:28:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S8a0h-0007yr-5y for qemu-devel@nongnu.org; Fri, 16 Mar 2012 12:28:16 -0400 Received: from isrv.corpit.ru ([86.62.121.231]:45782) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S8a0g-0007yi-Uj for qemu-devel@nongnu.org; Fri, 16 Mar 2012 12:28:11 -0400 Message-ID: <4F636A18.6060101@msgid.tls.msk.ru> Date: Fri, 16 Mar 2012 20:28:08 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <1331845217-21705-1-git-send-email-mjt@msgid.tls.msk.ru> <1331845217-21705-3-git-send-email-mjt@msgid.tls.msk.ru> <4F636700.9020201@codemonkey.ws> In-Reply-To: <4F636700.9020201@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv4 02/11] change iov_* function prototypes to be more appropriate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Paolo Bonzini , qemu-devel@nongnu.org On 16.03.2012 20:14, Anthony Liguori wrote: > On 03/15/2012 04:00 PM, Michael Tokarev wrote: >> Reorder arguments to be more natural, readable and >> consistent with other iov_* functions, and change >> argument names, from: >> iov_from_buf(iov, iov_cnt, buf, iov_off, size) >> to >> iov_from_buf(iov, iov_cnt, offset, buf, bytes) >> >> The result becomes natural English: > > I don't think this is a good idea. This is code churn for nothing but cosmetic reasons. I don't think there's a lot of value in that. I answered this just a few lines below: >> Now, it might look wrong to pay so much attention >> to so small things. But we've so many badly designed >> interfaces already so the whole thing becomes rather >> confusing or error prone. One example of this is >> previous commit and small discussion which emerged >> from it, with an outcome that the utility functions >> like these aren't well-understdandable, leading to >> strange usage cases. That's why I paid quite some >> attention to this set of functions and a few >> others in subsequent patches. Thanks, /mjt