[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 4/9] monitor: no need to save need_resume

From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v3 4/9] monitor: no need to save need_resume
Date: Mon, 27 Aug 2018 12:56:02 +0800
User-agent: Mutt/1.10.1 (2018-07-13)

On Sat, Aug 25, 2018 at 03:57:19PM +0200, Marc-André Lureau wrote:
> There is no need for per-command need_resume granularity, it should
> resume after running an non-oob command on oob-disabled monitor.
> Signed-off-by: Marc-André Lureau <address@hidden>
> Reviewed-by: Markus Armbruster <address@hidden>

Note that this series/patch still conflict with the "enable
out-of-band by default" series.

  [PATCH v6 00/13] monitor: enable OOB by default

I'm not against this patch to be merged since it has its r-b, but I
feel like we'd better judge on whether we still like the response
queue first, in case one day we'll need to add these things back.

When there could be functional changes around the code path I would
think we'd better keep the cleanup patches postponed a bit until those
functional changes are settled.  For now the functional part is decide
how to fix up the rest of out-of-band issues (my proposal is in the
series above which should solve everything that is related to
out-of-band to be fixed; if there is more, I'll continue to work on
it), whether we should enable it by default for 3.1 (my answer
is... yes...), and what to do with it.

If we found that it's too hard to enable it by default, I'm thinking
whether we can make it a persistent flag for monitor (maybe turning
the "x-oob" into a real "oob" and keep it, then we don't turn it on by
default), then we can let libvirt start working with out-of-band with
the flag.  After all it's actually working mostly (the pending issues
are only things like flow control for malicious/buggy clients, but
libvirt never had such an issue with it).


Peter Xu

reply via email to

[Prev in Thread] Current Thread [Next in Thread]