All of lore.kernel.org
 help / color / mirror / Atom feed
From: Orit Wasserman <owasserm@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: pbonzini@redhat.com, quintela@redhat.com, chegu_vinod@hp.com,
	qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v4 2/8] Add socket_writev_buffer function
Date: Sat, 23 Mar 2013 09:07:20 +0200	[thread overview]
Message-ID: <514D54A8.1050609@redhat.com> (raw)
In-Reply-To: <514C9014.9030607@redhat.com>

On 03/22/2013 07:08 PM, Eric Blake wrote:
> On 03/22/2013 01:30 AM, Orit Wasserman wrote:
> 
>>>>  
>>>> +static int socket_writev_buffer(void *opaque, struct iovec *iov, int iovcnt)
>>>
>>> Returning int...
>>>
>>>> +{
>>>> +    QEMUFileSocket *s = opaque;
>>>> +    ssize_t len;
>>>> +    ssize_t size = iov_size(iov, iovcnt);
>>>> +
>>>> +    len = iov_send(s->fd, iov, iovcnt, 0, size);
>>>> +    if (len < size) {
>>>> +        len = -socket_error();
>>>> +    }
>>>> +    return len;
>>>
>>> ...but len is an ssize_t.  If we send an iov with 2 gigabytes of data,
>>> this can wrap around to a negative int even though we send a positive
>>> amount of data.  Why not make the callback be typed to return ssize_t
>>> from the beginning (affects patch 1/8)?
>> At the moment it is not an issue but for the future we need to switch to ssize_t 
>> instead on int, I will change it.
>> We actually need to replace it all around the migration code but this should
>> be done in a different patch series.
> 
> I agree that the existing code base is in horrible shape with regards to
> int instead of ssize_t, and that it will take a different patch series
> to clean that up.  But why make that future patch harder?  New
> interfaces might as well be designed correctly, to limit the cleanup to
> the old interfaces, instead of making the cleanup job even harder.
> 
I agree completely! new interface should be designed correctly.

  reply	other threads:[~2013-03-23  7:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 18:34 [Qemu-devel] [PATCH v4 0/8] Migration: Remove copying of guest ram pages Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 1/8] Add QemuFileWritevBuffer QemuFileOps Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 2/8] Add socket_writev_buffer function Orit Wasserman
2013-03-21 19:35   ` Eric Blake
2013-03-22  7:30     ` Orit Wasserman
2013-03-22 17:08       ` Eric Blake
2013-03-23  7:07         ` Orit Wasserman [this message]
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 3/8] Update bytes_xfer in qemu_put_byte Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 4/8] Store the data to send also in iovec Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 5/8] Use writev ops if available Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 6/8] Add qemu_put_buffer_async Orit Wasserman
2013-03-21 19:38   ` Eric Blake
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 7/8] Use qemu_put_buffer_async for guest memory pages Orit Wasserman
2013-03-21 18:34 ` [Qemu-devel] [PATCH v4 8/8] coalesce adjacent iovecs Orit Wasserman
2013-03-21 19:41   ` Eric Blake

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=514D54A8.1050609@redhat.com \
    --to=owasserm@redhat.com \
    --cc=chegu_vinod@hp.com \
    --cc=eblake@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.