qemu-devel
[Top][All Lists]
Advanced

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

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


From: Igor Mammedov
Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus
Date: Wed, 24 Feb 2016 15:42:18 +0100

On Tue, 23 Feb 2016 18:26:20 -0300
Eduardo Habkost <address@hidden> 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 <address@hidden> 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.



reply via email to

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