Hi
On Wed, Oct 10, 2018 at 8:38 AM Peter Xu <peterx@redhat.com> wrote:
>
> On Tue, Oct 09, 2018 at 05:12:49PM +0400, Marc-André Lureau wrote:
> > Note: this patch will conflict with Peter "[PATCH v9 3/6] monitor:
> > remove "x-oob", turn oob on by default", but can be trivially updated.
> >
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > monitor.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/monitor.c b/monitor.c
> > index a25514490a..c175cf6f0d 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -4550,9 +4550,10 @@ void monitor_init(Chardev *chr, int flags)
> > bool use_oob = flags & MONITOR_USE_OOB;
> >
> > if (use_oob) {
> > - if (CHARDEV_IS_MUX(chr)) {
> > + if (!qemu_chr_has_feature(chr, QEMU_CHAR_FEATURE_GCONTEXT)) {
> > error_report("Monitor out-of-band is not supported with "
> > - "MUX typed chardev backend");
> > + "%s typed chardev backend",
> > + object_get_typename(OBJECT(chr)));
>
> This seems a bit confusing to me at the first glance since we forbid
> mux because not all frontends are ready to run outside main loop (and
> now we have mon_iothread so it'll be odd too to run anything
> non-monitor on that too...), rather than whether the backend can
> dynamically switch its context.
>
> I'm not sure, but do you mean you want to disable oob for backends
> like spice or braille? I just noticed that it seems even legal if we
> pipe a qmp monitor with a windows mouse...
yes, basically any chardev that doesn't handle the gcontext argument.
They match those that don't implement chr_update_read_handler at this point.
> I believe in all cases the commit message can be enhanced on
> explaining "why" of this patch. :)
ok, I'll keep the explicit mux case, even if it overlaps with gcontext
feature, and update commit message.
thanks
>
> Regards,
>
> --
> Peter Xu
>
--
Marc-André Lureau