qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: stefanha@gmail.com, Gerd Hoffmann <kraxel@redhat.com>,
	nab@linux-iscsi.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [PATCH 09/16] scsi-disk: Allocate iovec	dynamically
Date: Fri, 19 Nov 2010 13:46:25 +0100	[thread overview]
Message-ID: <4CE671A1.2080000@redhat.com> (raw)
In-Reply-To: <4CE66DF1.4000907@suse.de>

Am 19.11.2010 13:30, schrieb Hannes Reinecke:
> On 11/19/2010 12:43 PM, Kevin Wolf wrote:
>> Am 18.11.2010 17:28, schrieb Hannes Reinecke:
>>> On 11/18/2010 04:33 PM, Gerd Hoffmann wrote:
>>>>   Hi,
>>>>
>>>>> +static size_t scsi_req_iov_len(SCSIDiskReq *r)
>>>>> +{
>>>>> +    size_t iov_len = 0;
>>>>> +    int i;
>>>>> +
>>>>> +    for (i = 0; i<  r->iov_num; i++)
>>>>> +        iov_len += r->iov[i].iov_len;
>>>>> +
>>>>> +    return iov_len;
>>>>> +}
>>>>
>>>> You are aware that there is a QEMUIOVector type with helper functions
>>>> which keeps track of both number of elements and total size?
>>>>
>>> Yes. But I'm passing passing in an entire iovec to the request.
>>> However, the QEMUIOVector routines allow you to add only _one_
>>> element at a time, which is pretty wasteful here.
>>
>> Does the iov need to be changed afterwards, or why doesn't
>> qemu_iovec_init_external work here?
>>
> Oh, but I _do_ use qemu_iovec_init_external(); cf
> 
> hw/scsi_disk.c:scsi_read_data()
> 
> and yes, the iovec might be modified by the read/write operation;
> see below.
> 
>>> And I'm counting the resulting length of the iovec, which might have
>>> been changed by read/write operations. For which there is no generic
>>> function either.
>>
>> Can you explain which kind of read/write operations would change the
>> iov? This is not completely clear to me.
>>
> It is perfectly valid to send down an iovec larger than the command
> would fill out; eg for a SCSI Inquiry you could easily request 255
> bytes, but the command itself would only provide you with say 36 bytes.

Okay, so at the point where you create the iovec you don't have this
information yet but rather let the command emulation update the iovec
later. Makes sense.

That's probably something that QEMUIOVectors isn't really designed for,
so just forget what I said. :-)

Kevin

      reply	other threads:[~2010-11-19 12:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-18 14:47 [Qemu-devel] [PATCH 09/16] scsi-disk: Allocate iovec dynamically Hannes Reinecke
2010-11-18 15:33 ` [Qemu-devel] " Gerd Hoffmann
2010-11-18 16:28   ` Hannes Reinecke
2010-11-19 11:43     ` Kevin Wolf
2010-11-19 12:30       ` Hannes Reinecke
2010-11-19 12:46         ` Kevin Wolf [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CE671A1.2080000@redhat.com \
    --to=kwolf@redhat.com \
    --cc=hare@suse.de \
    --cc=kraxel@redhat.com \
    --cc=nab@linux-iscsi.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).