From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRmmH-0002Jk-KS for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:52:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRmmG-0004c4-8N for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:52:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1027) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRmmF-0004bx-QN for qemu-devel@nongnu.org; Wed, 01 Jun 2011 10:52:08 -0400 Message-ID: <4DE6520A.8080005@redhat.com> Date: Wed, 01 Jun 2011 17:51:54 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD6246F.4080802@gnu.org> <20110601084922.GA5863@redhat.com> <4DE62992.9070705@redhat.com> <20110601125124.GB12294@redhat.com> <4DE63F3E.6040805@redhat.com> <20110601143619.GB14626@redhat.com> In-Reply-To: <20110601143619.GB14626@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , qemu-devel , Stefan Hajnoczi On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote: > > > > So, if I am going to give this liberty with buffers to the driver, I > > _have_ to keep the size information. Otherwise, I agree that it is > > redundant and I will remove it. What poison do you prefer? > > > > Ah, I think I understand now. Both sense and data have in > fields that might only be used partially? > In that case I think I agree: it's best to require the use of separate > buffers for them, in this way used len will give you useful information > and you won't need sense_len and data_len: just a flag to > mark the fact that there *is* a sense buffer following. > And the num field does that. Do you mean to use the virtio iovec length to determine information about the message (like splitting it into buffers)? I think that's a bad idea. Splitting into buffers is a function of memory management. For example, a driver in userspace (or a nested guest) will have additional fragmentation into 4K pages after it passes through the iommu. Let's not mix layers here. -- error compiling committee.c: too many arguments to function