On Mon, Aug 01, 2016 at 13:19:40 +0200, Peter Krempa wrote:
> On Mon, Aug 01, 2016 at 12:40:31 +0200, Ján Tomko wrote:
> > On Mon, Aug 01, 2016 at 06:30:07AM +0200, Peter Krempa wrote:
> > >The prettified JSON string already contains a newline so don't print
> > >another one. This allows to pipe the json output (in conjunction with
> > >the --quiet option) to files without having to truncate them afterwards.
> > >---
> > > tools/virsh-domain.c | 19 +++++++++----------
> > > 1 file changed, 9 insertions(+), 10 deletions(-)
> > >
> > >diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> > >index 6c1bc2f..45fce76 100644
> > >--- a/tools/virsh-domain.c
> > >+++ b/tools/virsh-domain.c
> > >@@ -8944,6 +8944,7 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd)
> > > virBuffer buf = VIR_BUFFER_INITIALIZER;
> > > bool pad = false;
> > > virJSONValuePtr pretty = NULL;
> > >+ char *prettystr = NULL;
> > >
> > > VSH_EXCLUSIVE_OPTIONS("hmp", "pretty");
> > >
[...]
> > Do we need the fallback? AFAIK there are only two issues possible when
> > prettifying the string:
> > * the system is out of memory
> > possibly impossible, erroring out or even aborting virsh are
> > acceptable here
> > * virDomainQemuMonitorCommand did not return a JSON output
> > For a domain with JSON monitor, the remote side calls virJSONValueToString,
> > so this could only reasonably happen with a domain that only has HMP.
> > If we error out on the --hmp --pretty combination, we can error out
> > here too and do not need to fall back to raw output.
>
> Hmm, that's true. The slight change in semantics should not be an issue.
Actually I retract my statement. It's not true. If the VM uses just the
HMP monitor then the conversation is done in HMP regardless of the flag
and thus the fallback is still necessary.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list