Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On Thu, Dec 13, 2018 at 11:27 PM Eric Blake wrote: > On 12/13/18 11:44 AM, Nir Soffer wrote: > > >> 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. > >> > > > > nbd is awesome, but much more complicated to use for testing. You need > to: > > > > 1. start qemu-nbd > > 2. wait until it is ready > > 3. use nbd client (we have one now), or connect the qemu-nbd to > /dev/ndbX, > > which on > >Fedora 28 leaves stale /dev/nbdX devices after disconnection > >(I reported this few month ago here). > > Is that true even when you use 'qemu-nbd -d /dev/nbdX' after you are done? > It was true when I reported this here: http://lists.nongnu.org/archive/html/qemu-block/2018-07/msg00168.html
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On 12/13/18 11:44 AM, Nir Soffer wrote: 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. nbd is awesome, but much more complicated to use for testing. You need to: 1. start qemu-nbd 2. wait until it is ready 3. use nbd client (we have one now), or connect the qemu-nbd to /dev/ndbX, which on Fedora 28 leaves stale /dev/nbdX devices after disconnection (I reported this few month ago here). Is that true even when you use 'qemu-nbd -d /dev/nbdX' after you are done? 4. finally disconnect and wait until qemu-nbd terminates qemu-io is so much easier to use, we need to make it more machine friendly. Or rather, if there is something that a machine needs to drive, we should figure out if qemu-img can be taught to do it instead of hacking around the issue with qemu-io. When it comes to extracting portions of a disk, qemu-img convert coupled with the raw driver's offset/length gets us quite a bit of functionality - even if it's clunky to come up with the command line, it can be programmed, and doesn't suffer from having to post-process arbitrary qemu-io output changes. 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. Add --output json? Who's volunteering to do it? I've got too much else going on to spend time on such a project. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On Thu, Dec 13, 2018 at 4:05 PM 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 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. > nbd is awesome, but much more complicated to use for testing. You need to: 1. start qemu-nbd 2. wait until it is ready 3. use nbd client (we have one now), or connect the qemu-nbd to /dev/ndbX, which on Fedora 28 leaves stale /dev/nbdX devices after disconnection (I reported this few month ago here). 4. finally disconnect and wait until qemu-nbd terminates qemu-io is so much easier to use, we need to make it more machine friendly. > > 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 hex dump is nice for interactive use, but not for automated tests, unless you test by comparing the output of the tool to previously recorded output like iotests do. We don't use tool output for testing, it is very fragile and hard to maintain. > 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. > Add --output json? Nir
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On Thu, Dec 13, 2018 at 12:47 PM Daniel P. Berrangé wrote: > On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote: > > On Thu, Dec 13, 2018 at 12:13 AM Eric Blake 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. > We use qemu-io for testing changes to tiny images, so multiple copies are fine. Nir
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
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 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
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
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 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
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
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 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. Kevin
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On Thu, Dec 13, 2018 at 01:52:29AM +0200, Nir Soffer wrote: > On Thu, Dec 13, 2018 at 12:13 AM Eric Blake 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 :|
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On 12/12/18 5:52 PM, Nir Soffer wrote:
On Thu, Dec 13, 2018 at 12:13 AM Eric Blake 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)
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.
@@ -723,8 +725,8 @@ static int read_f(BlockBackend *blk, int argc, char **argv)
print_cvtnum_err(count, argv[optind]);
return count;
} else if (count > BDRV_REQUEST_MAX_BYTES) {
-printf("length cannot exceed %" PRIu64 ", given %s\n",
- (uint64_t)BDRV_REQUEST_MAX_BYTES, argv[optind]);
+fprintf(stderr, "length cannot exceed %" PRIu64 ", given %s\n",
+(uint64_t)BDRV_REQUEST_MAX_BYTES, argv[optind]);
return -EINVAL;
}
@@ -738,19 +740,22 @@ static int read_f(BlockBackend *blk, int argc, char
**argv)
}
if ((pattern_count < 0) || (pattern_count + pattern_offset > count)) {
-printf("pattern verification range exceeds end of read data\n");
+fprintf(stderr,
+"pattern verification range exceeds end of read data\n");
return -EINVAL;
Note that 'read -P ...' can fail for both pattern verification failure,
and for other reasons, both before and after this patch. The only thing
this patch is doing is changing where the failure messages are output.
Or is your complaint that your existing code is already catering to
older qemu that had 0 exit status, and parsing stdout for a specific
string rather than trusting exit status, and now stdout won't have that
specific string? qemu-io is not quite as worried about backwards
compatibility as qemu-img or qemu proper, but at least knowing what
might break might help us design something more user-friendly.
Can you redirect qemu-io to output both stdout and stderr to the same
file, if you have to parse the answers to learn if verification has failed?
And your idea of having distinguished error codes for verification fail
vs. overall failure makes some sense, but it would require some major
rework (right now, returning -errno codes does not really tell the
caller what exit status to report).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: [Qemu-devel] [Qemu-block] [PATCH RFC] qemu-io: Prefer stderr for error messages
On Thu, Dec 13, 2018 at 12:13 AM Eric Blake 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)
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.
Nir
>
> Reported-by: Richard W.M. Jones
> Signed-off-by: Eric Blake
> ---
>
> RFC because at least iotest 60 (found by -qcow2 -g quick) breaks due
> to reordering of output lines, and I'd rather know if we like this
> idea before bothering to revisit all affected iotests (including
> discovering if other slower ones have similar problems).
>
> qemu-io-cmds.c | 120 ++---
> qemu-io.c | 3 +-
> 2 files changed, 67 insertions(+), 56 deletions(-)
>
> diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
> index 5363482213b..e4f3925b5c9 100644
> --- a/qemu-io-cmds.c
> +++ b/qemu-io-cmds.c
> @@ -184,14 +184,14 @@ static void print_cvtnum_err(int64_t rc, const char
> *arg)
> {
> switch (rc) {
> case -EINVAL:
> -printf("Parsing error: non-numeric argument,"
> - " or extraneous/unrecognized suffix -- %s\n", arg);
> +fprintf(stderr, "Parsing error: non-numeric argument,"
> +" or extraneous/unrecognized suffix -- %s\n", arg);
> break;
> case -ERANGE:
> -printf("Parsing error: argument too large -- %s\n", arg);
> +fprintf(stderr, "Parsing error: argument too large -- %s\n", arg);
> break;
> default:
> -printf("Parsing error: %s\n", arg);
> +fprintf(stderr, "Parsing error: %s\n", arg);
> }
> }
>
> @@ -312,7 +312,7 @@ static int parse_pattern(const char *arg)
>
> pattern = strtol(arg, &endptr, 0);
> if (pattern < 0 || pattern > UCHAR_MAX || *endptr != '\0') {
> -printf("%s is not a valid pattern byte\n", arg);
> +fprintf(stderr, "%s is not a valid pattern byte\n", arg);
> return -1;
> }
>
> @@ -421,14 +421,16 @@ create_iovec(BlockBackend *blk, QEMUIOVector *qiov,
> char **argv, int nr_iov,
> }
>
> if (len > BDRV_REQUEST_MAX_BYTES) {
> -printf("Argument '%s' exceeds maximum size %" PRIu64 "\n", arg,
> - (uint64_t)BDRV_REQUEST_MAX_BYTES);
> +fprintf(stderr,
> +"Argument '%s' exceeds maximum size %" PRIu64 "\n", arg,
> +(uint64_t)BDRV_REQUEST_MAX_BYTES);
> goto fail;
> }
>
> if (count > BDRV_REQUEST_MAX_BYTES - len) {
> -printf("The total number of bytes exceed the maximum size %"
> PRIu64
> - "\n", (uint64_t)BDRV_REQUEST_MAX_BYTES);
> +fprintf(stderr,
> +"The total number of bytes exceed the maximum size %"
> PRIu64
> +"\n", (uint64_t)BDRV_REQUEST_MAX_BYTES);
> goto fail;
> }
>
> @@ -723,8 +725,8 @@ static int read_f(BlockBackend *blk, int argc, char
> **argv)
> print_cvtnum_err(count, argv[optind]);
> return count;
> } else if (count > BDRV_REQUEST_MAX_BYTES) {
> -printf("length cannot exceed %" PRIu64 ", given %s\n",
> - (uint64_t)BDRV_REQUEST_MAX_BYTES, argv[optind]);
> +fprintf(stderr, "length cannot exceed %" PRIu64 ", given %s\n",
> +(uint64_t)BDRV_REQUEST_MAX_BYTES, argv[optind]);
> return -EINVAL;
> }
>
> @@ -738,19 +740,22 @@ static int read_f(BlockBackend *blk, int argc, char
> **argv)
> }
>
> if ((pattern_count < 0) || (pattern_count + pattern_offset > count)) {
> -printf("pattern verification range exceeds end of read data\n");
> +fprintf(stderr,
> +"pattern verification range exceeds end of read data\n");
> return -EINVAL;
> }
>
> if (bflag) {
> if (!QEMU_IS_ALIGNED(offset, BDRV_SECTOR_SIZE)) {
> -printf("%" PRId64 " is not a sector-aligned value for
> 'offset'\n",
> - offset);
> +fprintf(stderr,
> +"%" PRId64 " is not a sector-aligned value for
> 'offset'\n",
> +offset);
> return -EINVAL;
> }
> if (!QEMU_IS_ALIGNED(count, BDRV_SECTOR_SIZE)) {
> -printf("%"PRId64" is not a sector-aligned value for 'count'\n",
> - count);
> +fprintf(stderr,
> +"%"PRId64" is not a sector-aligned value for 'count'\n",
> +count);
> return -EINVAL;
> }
> }
> @@ -766,7 +771,7 @@ static int read_f(BlockBackend *blk,
