qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for err


From: Eric Blake
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
Date: Thu, 13 Dec 2018 08:23:43 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 12/13/18 8:05 AM, Kevin Wolf wrote:
Am 13.12.2018 um 11:47 hat Daniel P. Berrangé geschrieben:
On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote:
On Thu, Dec 13, 2018 at 12:13 AM Eric Blake <address@hidden> 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.

qemu-io processes more than just a single command. What would the exit
code be if one of the commands succeeds, one gets an I/O error, and the
third one succeeds for I/O, but fails pattern verification?

The things is, qemu-io was never meant to be used by other
applications that need to process the results, it's a tool for testing
and debugging. If we had meant it to be used by other programs, we would
have given it a machine-friendly interface.

The machine-friendly interface to the QEMU block layer is qemu-nbd.

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.

'read -v' produces a hex dump on stdout, but you still need to separate
it from the other output and then parse the hexdump.

The human interface of qemu-io is honestly just not the right tool for
the job, and adding one-off tweaks to make it a little bit less horrible
to use for machines isn't the right approach because it's still not a
proper machine protocol.

I actually agree with that sentiment - qemu-io is NOT a program where we promise backwards compatibility (we're not going to break it without reason, because we DO have to keep iotests running, but outside of iotests, we are less concerned if other uses break).

But it DOES sound like teaching 'qemu-img convert' to optionally convert only a subset of a file may be useful (I already tried once to make 'qemu-img dd' smarter, and the conclusion at the time is that it would be better to just make qemu-img dd be syntactic sugar for a full-featured qemu-img convert, which means making convert take an offset and range limit to the source, as well as a separate offset into the destination, for easily extracting portions of one file into portions of another). And I also agree that qemu-nbd already has offset and range support.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]