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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]

On Wed, Feb 24, 2016 at 03:42:18PM +0100, Igor Mammedov wrote:
> On Tue, 23 Feb 2016 18:26:20 -0300
> Eduardo Habkost <ehabkost@redhat.com> wrote:
> 
> > On Tue, Feb 23, 2016 at 10:46:45AM +0100, Igor Mammedov wrote:
> > > On Mon, 22 Feb 2016 13:54:32 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:  
> > [...]
> > > > This is why Eduardo suggested - and I agreed - that it's probably
> > > > better to implement the "1st layer" as an internal structure/interface
> > > > only, and implement the 2nd layer on top of that.  When/if we need to
> > > > we can revisit a user-accessible interface to the 1st layer.  
> > > We are going around QOM based CPU introspecting interface for
> > > years now and that's exactly what 2nd layer is, just another
> > > implementation. I've just lost hope in this approach.
> > > 
> > > What I'm suggesting in this RFC is to forget controversial
> > > QOM approach for now and use -device/device_add + QMP introspection,  
> > 
> > You have a point about it looking controversial, but I would like
> > to understand why exactly it is controversial. Discussions seem
> > to get stuck every single time we try to do something useful with
> > the QOM tree, and I don't undertsand why.
> Maybe because we are trying to create a universal solution to fit
> ALL platforms? And every time some one posts patches to show
> implementation, it would break something in existing machine
> or is not complete in terms of how interface would work wrt
> mgmt/CLI/migration.
> 
> > 
> > > 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.

Yeah, I'm starting to come around to that point of view.  I'm not yet
convinced that this specific QMP interface is the right way to go, but
I'm certainly think about it.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]