qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] io: add new qio_channel_{readv, writev, read, write}_all functions
Date: Thu, 31 Aug 2017 10:17:23 +0100	[thread overview]
Message-ID: <20170831091723.GC17315@redhat.com> (raw)
In-Reply-To: <baf58715-49f6-6608-d469-062086c4fdd0@redhat.com>

On Wed, Aug 30, 2017 at 02:34:59PM -0500, Eric Blake wrote:
> On 08/30/2017 08:56 AM, Daniel P. Berrange wrote:
> > These functions wait until they are able to read / write the full
> > requested data buffer(s).
> > 
> 
> Hmm, sounds like the NBD code would benefit from using this in a
> followup patch.
> 
> > Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> > ---
> > 
> > This patch combines these two previous proposals:
> > 
> >  - https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg01536.html
> >  - https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg04041.html
> > 
> > and switches the test suite over to use the new APIs so we get
> > coverage by all the tests/test-io-channel-*  test programs
> > 
> 
> >  /**
> > + * qio_channel_readv_all:
> > + * @ioc: the channel object
> > + * @iov: the array of memory regions to read data into
> > + * @niov: the length of the @iov array
> > + * @errp: pointer to a NULL-initialized error object
> > + *
> > + * Read data from the IO channel, storing it in the
> > + * memory regions referenced by @iov. Each element
> > + * in the @iov will be fully populated with data
> > + * before the next one is used. The @niov parameter
> > + * specifies the total number of elements in @iov.
> > + *
> > + * The function will wait for all requested data
> > + * to be read, yielding from the current couroutine
> 
> s/couroutine/coroutine/
> 
> > + * if required.
> > + *
> > + * If end-of-file occurrs before all requested data
> 
> s/occurrs/occurs/
> 
> > + * has been read, an error will be reported.
> > + *
> > + * Returns: 0 if all bytes were read, or -1 on error
> > + */
> 
> > +/**
> > + * qio_channel_writev_all:
> > + * @ioc: the channel object
> > + * @iov: the array of memory regions to write data from
> > + * @niov: the length of the @iov array
> > + * @errp: pointer to a NULL-initialized error object
> > + *
> > + * Write data to the IO channel, reading it from the
> > + * memory regions referenced by @iov. Each element
> > + * in the @iov will be fully sent, before the next
> > + * one is used. The @niov parameter specifies the
> > + * total number of elements in @iov.
> > + *
> > + * The function will wait for all requested data
> > + * to be written, yielding from the current couroutine
> 
> s/couroutine/coroutine/
> 
> > +++ b/io/channel.c
> 
> > +int qio_channel_readv_all(QIOChannel *ioc,
> 
> > +    while (nlocal_iov > 0) {
> > +        ssize_t len;
> > +        len = qio_channel_readv(ioc, local_iov, nlocal_iov, errp);
> > +        if (len == QIO_CHANNEL_ERR_BLOCK) {
> > +            qio_channel_wait(ioc, G_IO_IN);
> > +            continue;
> > +        } else if (len < 0) {
> > +            error_setg_errno(errp, EIO,
> > +                             "Channel was not able to read full iov");
> 
> Should we report -len instead of EIO here?

No, QIO methods never return errno values, since channel implementations
are not guaranteed to be calling commands that return errnos. eg the
TLS wrapper calls gnutls which has no errno values reported.

If fact, though, we should just not call error_setg_errno() at all,
since the qio_channel_readv method has already populated 'errp'.

> 
> > +int qio_channel_writev_all(QIOChannel *ioc,
> 
> > +    while (nlocal_iov > 0) {
> > +        ssize_t len;
> > +        len = qio_channel_writev(ioc, local_iov, nlocal_iov, errp);
> > +        if (len == QIO_CHANNEL_ERR_BLOCK) {
> > +            qio_channel_wait(ioc, G_IO_OUT);
> > +            continue;
> > +        }
> > +        if (len < 0) {
> > +            error_setg_errno(errp, EIO,
> > +                             "Channel was not able to write full iov");
> 
> and again
> 
> With the typos fixed, and either an explanation why EIO is better or
> else a fix to preserve errno,

Again, we should not call error_setg_errno at all, since errp is
already populated.

> 
> Reviewed-by: Eric Blake <eblake@redhat.com>




Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

      reply	other threads:[~2017-08-31  9:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 13:56 [Qemu-devel] [PATCH] io: add new qio_channel_{readv, writev, read, write}_all functions Daniel P. Berrange
2017-08-30 19:34 ` Eric Blake
2017-08-31  9:17   ` Daniel P. Berrange [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=20170831091723.GC17315@redhat.com \
    --to=berrange@redhat.com \
    --cc=eblake@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 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).