On Thu, 25 Feb 2016 14:52:06 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Wed, Feb 24, 2016 at 03:42:18PM +0100, Igor Mammedov wrote: > > On Tue, 23 Feb 2016 18:26:20 -0300 > > Eduardo Habkost <ehabk...@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 <da...@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. > > That's true. > > > > > > > > > > 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.
