Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus

[Eduardo Habkost]

On Mon, Feb 29, 2016 at 04:42:58PM +0100, Igor Mammedov wrote:
[...]
> > > > > i.e. completely split interface from how boards internally implement
> > > > > CPU hotplug.    
> > > > 
> > > > A QOM-based interface may still split the interface from how
> > > > boards internally implement CPU hotplug. They don't need to
> > > > affect the device tree of the machine, we just need to create QOM
> > > > objects or links at predictable paths, that implement certain
> > > > interfaces.  
> > > Beside of not being able to reach consensus for a long time,
> > > I'm fine with isolated QOM interface if it allow us to move forward.
> > > However static QMP/QAPI interface seems to be better describing and
> > > has better documentation vs current very flexible poorly self-describing 
> > > QOM.  
> > 
> > You have a good point: QMP is more stable and better documented.
> > QOM is easier for making experiments, and I would really like to
> > see it being used more. But if we still don't understand the
> > requirements enough to design a QMP interface, we won't be able
> > to implement the same functionality using QOM either.
> > 
> > If we figure out the requirements, I believe we should be able to
> > design equivalent QMP and QOM interfaces.
> So not to stall CPU hotplug progress, I'd start with stable QMP query
> interface for general use, leaving experimental QOM interface for later
> as difficult to discover and poorly documented one from mgmt pov,
> meaning mgmt would have to:
>  - instantiate a particular machine type to find if QOM interface is 
> supported,
>    i.e. '-machine none' won't work with it as it's board depended VS static 
> compile time qapi-schema in QMP case
>  - execute a bunch of qom-list/qom-read requests over wire to enumerate/query
>    objects starting at some fixed entry point (/machine/cpus) VS a single 
> command that does 'atomic' enumeration in QMP case.

Agreed.

-- 
Eduardo