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

[Kevin Wolf <kwolf@redhat.com>]

Am 13.12.2018 um 15:23 hat Eric Blake geschrieben:
> 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 <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.
> > 
> > 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.

Can't you actually already achieve this with --image-opts and a raw
filter that has the offset/size options set?

It's not as nice as with a separate option, but it should do the job.

Kevin