On 9/12/19 1:54 PM, Eric Blake wrote:
We decided to not request the "base:allocation" context by
default (if
a client wants to use block_status on a different context, then they'd
have to get any default request out of the way); however, block status
is useless without at least one meta context. This adds a convenience
knob for requesting that, and has the nice benefit of working with the
--connect command line option (previously, if you wanted to use
block_status, you could not use --connect, because requesting the meta
context must happen before the connection).
---
sh/nbdsh.pod | 9 +++++++
python/nbdsh.py | 4 +++
sh/Makefile.am | 4 ++-
sh/test-context.sh | 62 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 78 insertions(+), 1 deletion(-)
create mode 100755 sh/test-context.sh
diff --git a/sh/nbdsh.pod b/sh/nbdsh.pod
index d7fc315..6c540c7 100644
--- a/sh/nbdsh.pod
+++ b/sh/nbdsh.pod
@@ -56,6 +56,15 @@ __EXAMPLES_HEXDUMP__
Display brief command line help and exit.
+=item B<-b>
Burning -b may be premature (we may want a --block-size parameter, for
example). Similarly, -a (allocation, vs. append) or -m (meta context,
vs. memory) are not necessarily good letters.
If I just stick with long options for now, note that Python accepts --b
(or --ba) as unambiguously short for --base-allocation (at least as long
as there are no other --b... options added); we could also add a -b-a
synonym.
Also, we may want to revisit our decision to have no meta contexts
requested by default. Requesting "base:allocation" by default, but
allowing clients a way to unrequest that (in order request a different
context by itself, rather than appending a second context to our
default) might be an interesting idea. In general, a client that is not
going to call nbd_block_status is going to start slightly faster if we
don't bother negotiating contexts, but at the same time, is not going to
be negatively impacted during the bulk of the runtime if we defaulted to
negotiating base:allocation. If we _do_ default to negotiating
base:allocation, then we don't need an option at all.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org