From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48344) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbUQu-0007v3-PT for qemu-devel@nongnu.org; Thu, 22 Nov 2012 05:55:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbUQt-0001ee-LS for qemu-devel@nongnu.org; Thu, 22 Nov 2012 05:55:00 -0500 Received: from mail-ie0-f173.google.com ([209.85.223.173]:61545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbUQt-0001ea-FX for qemu-devel@nongnu.org; Thu, 22 Nov 2012 05:54:59 -0500 Received: by mail-ie0-f173.google.com with SMTP id e13so1640860iej.4 for ; Thu, 22 Nov 2012 02:54:58 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50AE0479.50404@redhat.com> Date: Thu, 22 Nov 2012 11:54:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1353522781-12721-1-git-send-email-stefanha@redhat.com> <1353522781-12721-10-git-send-email-stefanha@redhat.com> <50ADF195.4030204@redhat.com> <20121122094507.GA24617@redhat.com> <50ADF5DB.7060201@redhat.com> <20121122103845.GA24951@redhat.com> In-Reply-To: <20121122103845.GA24951@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 09/12] iov: add iov_get_ptr() to reference vector data List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Kevin Wolf , Anthony Liguori , dkoch@cloudswitch.com, qemu-devel@nongnu.org, Michael Roth , Blue Swirl , khoa@us.ibm.com, Stefan Hajnoczi , Asias He Il 22/11/2012 11:38, Michael S. Tsirkin ha scritto: >> > The code is a little simpler, because we know the footer is 1 byte only. > > Yes but the APIs don't make sense in the generic case > of >1 byte: users will have to code up two paths for when > the buffer they want to access gets scattered across. That would be premature optimization; with >1 byte you just use iov_from/to_buf. BTW, something like this function is also useful for the broken SCSI outhdr ("the CDB starts after the common outhdr and is in a single iovec"). But the API must be changed slightly, as in my answer to Stefan. > If the point is to avoid scanning iov vector when data is towards the > end of the iov, then this does sound reasonable. In that case IMHO we > should just have accessors that work back from end of the iov. E.g. > > size_t iov_from_buf_end(const struct iovec *iov, unsigned int iov_cnt, > size_t offset, const void *buf, size_t bytes) That's also a possibility. Paolo