qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Nir Soffer <nsoffer@redhat.com>
Cc: Eric Blake <eblake@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
Date: Thu, 13 Dec 2018 10:47:04 +0000	[thread overview]
Message-ID: <20181213104704.GD5171@redhat.com> (raw)
In-Reply-To: <CAMRbyyuZ81fyHYTQSHPXhjYoLFz6nzsxc30PNJdWRkqm=14RRA@mail.gmail.com>

On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote:
> On Thu, Dec 13, 2018 at 12:13 AM Eric Blake <eblake@redhat.com> wrote:
> >
> > When a qemu-io command fails, it's best if the failure message
> > goes to stderr rather than stdout.
> 
> This makes sense, but it will break users like this:
> 
> https://github.com/oVirt/vdsm/blob/a2836b1d58ffaa0f48cc9c814b6002161a81f044/tests/storage/qemuio.py#L45
> 
> We need a way to detect qemu-io verification failures, maybe a special
> exit code?
> 
> 0 - verification succeeded
> 1 - verification failed
> 2 - other error (e.g no such file)

This makes sense. We should *never* expect applications to parse the
messages on stdout/err, because we reserve the right to change text
arbitrarily at any time. So we need to use exit status IMHO.

> Or, if qemu-io had a way to read data and write it to stdout, we could
> compare the data and avoid the need for special exit code.

That should be trivial to do, and quite desirable too IMHO - libvirt would
in fact quite like such a feature, as it would let us support format
conversions when using our upload/download APIs, without having to create
intermediate files.  Alternatively 'qemu-img convert' could allow for
/dev/stdin and /dev/stdout as raw files, but that looks considerably
harder to implement.

For your usecase that feels rather inefficient as you're introducing
multiple data copies, which will be bad for large images. Much better
if we just make qemu-io set good exit codes.

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 :|

  parent reply	other threads:[~2018-12-13 10:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 22:04 [Qemu-devel] [PATCH RFC] qemu-io: Prefer stderr for error messages Eric Blake
2018-12-12 22:11 ` Richard W.M. Jones
2018-12-12 23:52 ` [Qemu-devel] [Qemu-block] " Nir Soffer
2018-12-13  1:26   ` Eric Blake
2018-12-13 10:47   ` Daniel P. Berrangé [this message]
2018-12-13 14:05     ` Kevin Wolf
2018-12-13 14:23       ` Eric Blake
2018-12-13 14:34         ` Kevin Wolf
2018-12-13 17:44       ` Nir Soffer
2018-12-13 21:27         ` Eric Blake
2018-12-13 22:13           ` Nir Soffer
2018-12-13 17:15     ` Nir Soffer
2018-12-13 10:11 ` [Qemu-devel] " Daniel P. Berrangé
2018-12-13 14:22   ` Kevin Wolf
2018-12-13 16:02     ` Richard W.M. Jones
2018-12-13 12:21 ` Wainer dos Santos Moschetta
2018-12-13 14:04   ` Eric Blake
2018-12-13 14:38 ` Kevin Wolf

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=20181213104704.GD5171@redhat.com \
    --to=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nsoffer@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).