[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v5 12/26] qmp: negociate QMP capabilities
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [RFC v5 12/26] qmp: negociate QMP capabilities |
Date: |
Sat, 16 Dec 2017 13:34:58 +0800 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Fri, Dec 15, 2017 at 09:53:53PM +0800, Fam Zheng wrote:
> On Fri, 12/15 13:26, Stefan Hajnoczi wrote:
> > > > QEMU always offers the 'oob' capability, even if the monitor does not
> > > > support it. Should it send 'oob' only when mon->use_io_thr to make
> > > > things easier for clients?
Agree.
> > >
> > > So should we firstly agree on whether the capabilities is on the current
> > > monitor
> > > connection or QEMU as a whole?
> >
> > It's more flexible to allow per-connection capabilities. Is there a
> > reason against it?
>
> No, I just think either way we should document it. So if we define it
> per-connection, like you said, "oob" shouldn't be sent in the greeting
> message,
> and patch 11 need to be updated.
Yeah, that's where I'll do the update. Thanks!
--
Peter Xu
- Re: [Qemu-devel] [RFC v5 11/26] qmp: introduce QMPCapability, (continued)
[Qemu-devel] [RFC v5 12/26] qmp: negociate QMP capabilities, Peter Xu, 2017/12/05
[Qemu-devel] [RFC v5 13/26] qmp: introduce some capability helpers, Peter Xu, 2017/12/05
[Qemu-devel] [RFC v5 14/26] monitor: introduce monitor_qmp_respond(), Peter Xu, 2017/12/05
[Qemu-devel] [RFC v5 15/26] monitor: let suspend_cnt be thread safe, Peter Xu, 2017/12/05