On 8/20/19 6:42 AM, Richard W.M. Jones wrote:
I'm very lukewarm on this one. Why is this a plugin-level
feature?
For other protocol things we have used command line options (eg. -o /
-n and the various TLS options).
A command-line option does sound nicer, especially since disabling
structured reply support affects more than just extents. I'll spin a v2
along those lines (and actually suspect it will make for a smaller patch).
Also I understand that this found a bug in qemu-nbd which is great,
but why else would it ever be needed?
If nothing else, it's useful for testing sane client behavior in the
face of older servers. It can also be used for testing whether the time
spent in querying allocation information even when that information
always returns allocated, vs. disabling structured replies so the client
can't get block status at all, would make any difference. And down the
road when we implement v3 api with sparse read support, it might be
useful to work around buggy clients that can't correctly handle sparse
reads when they try to negotiate SR, but which behave fine with simple
reads.
Maybe we can control this with some kind of command line protocol
flags, and try to emphasize that, like the -D flag, this is for
testing only and is not API.
I think it belongs in the same boat as -o/-n on the command line, but
you've convinced me it does not need to be part of the backend callback
structure.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org