From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55140) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbUgz-0002Ro-2Y for qemu-devel@nongnu.org; Thu, 22 Nov 2012 06:11:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbUgt-0006pg-Ah for qemu-devel@nongnu.org; Thu, 22 Nov 2012 06:11:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbUgt-0006pb-1W for qemu-devel@nongnu.org; Thu, 22 Nov 2012 06:11:31 -0500 Date: Thu, 22 Nov 2012 13:14:12 +0200 From: "Michael S. Tsirkin" Message-ID: <20121122111412.GA25594@redhat.com> 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> <50AE0479.50404@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AE0479.50404@redhat.com> 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: Paolo Bonzini Cc: Kevin Wolf , Anthony Liguori , dkoch@cloudswitch.com, qemu-devel@nongnu.org, Michael Roth , Blue Swirl , khoa@us.ibm.com, Stefan Hajnoczi , Asias He On Thu, Nov 22, 2012 at 11:54:49AM +0100, Paolo Bonzini wrote: > 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. If the API makes it very clear that it only works for 1 byte I would have no objection. > 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. The scsi command is special in that the length is iov_length. It's all legacy anyway so I think we can just assume it's the second s/g entry: iov[1].iov_length. We should probably have a wrapper that gets it after checking iov_cnt > 1. size_t iov_get_seg_length(...) { assert(iov_cnt <= idx); return iov[idx].iov_length; } Rusty says he'll put the length of the command in the buffer in the future, so we will have if (new_cmd_feature) iov_to_buf(.... &len) else len = iov_get_seg_length > > 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