From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYldl-0005eN-Bb for qemu-devel@nongnu.org; Wed, 24 Feb 2016 21:26:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYldi-0005eu-Vz for qemu-devel@nongnu.org; Wed, 24 Feb 2016 21:26:53 -0500 Received: from ozlabs.org ([103.22.144.67]:49215) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYldi-0005e7-L2 for qemu-devel@nongnu.org; Wed, 24 Feb 2016 21:26:50 -0500 Date: Thu, 25 Feb 2016 12:05:20 +1100 From: David Gibson Message-ID: <20160225010520.GC22216@voom.redhat.com> References: <878u2lhi8i.fsf@blackfin.pond.sub.org> <20160216113655.2bbb9988@nial.brq.redhat.com> <20160218033952.GG15224@voom.fritz.box> <20160218113739.64b02461@nial.brq.redhat.com> <20160219043848.GZ15224@voom.fritz.box> <20160219164911.091b4351@nial.brq.redhat.com> <20160222025432.GD2808@voom.fritz.box> <20160223104645.6b64f60c@nial.brq.redhat.com> <20160223212620.GF3901@thinpad.lan.raisama.net> <20160224154218.5bd84960@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3siQDZowHQqNOShm" Content-Disposition: inline In-Reply-To: <20160224154218.5bd84960@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: lvivier@redhat.com, thuth@redhat.com, Peter Krempa , Eduardo Habkost , aik@ozlabs.ru, Markus Armbruster , qemu-devel@nongnu.org, agraf@suse.de, abologna@redhat.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, afaerber@suse.de --3siQDZowHQqNOShm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2016 at 03:42:18PM +0100, Igor Mammedov wrote: > On Tue, 23 Feb 2016 18:26:20 -0300 > Eduardo Habkost wrote: >=20 > > On Tue, Feb 23, 2016 at 10:46:45AM +0100, Igor Mammedov wrote: > > > On Mon, 22 Feb 2016 13:54:32 +1100 > > > David Gibson wrote: =20 > > [...] > > > > This is why Eduardo suggested - and I agreed - that it's probably > > > > better to implement the "1st layer" as an internal structure/interf= ace > > > > 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. =20 > > > 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. > > >=20 > > > What I'm suggesting in this RFC is to forget controversial > > > QOM approach for now and use -device/device_add + QMP introspection, = =20 > >=20 > > 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. >=20 > >=20 > > > i.e. completely split interface from how boards internally implement > > > CPU hotplug. =20 > >=20 > > 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. --=20 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 --3siQDZowHQqNOShm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWzlNQAAoJEGw4ysog2bOStRcP+QEH0Ro1ys/0yscPw2LM5yeH aLWmPiCNXJ/4SNk6wW7Ik0WhDGjE8RaVRunzrmYbd3x3lDeqhtC+H58A+qRZnutA hblVq6twVMWZvSuK2WdLlgq86ItTIwZYCGMiWAL2+RRdKIcO2gT7uY0KK5UdIvlg diRivCUtj9qpWRsPo6UpPU7syjwyZ0It6U1ncA9k2931y3p01v7eJMgVCuNdrHMl 7v9g133fkO6RDv5YHNi3usC7TJMaxjq2TLcp8vaFcTfXsc9Ql1Y9YrdF0Lfuzxeu mqYqj+EUYX4RpmWhzbj7VgkGM2ndDLG9XgeiROEGE58wa8MCD5i6X+rLyE5DDyTp dLrYE8f3cvJnva97z3rB9aD63DpijI4aA4B2oLcMzf/MhumWdWK772Z/cqfT4lWi 9kk1WuSHWmYpczFzpY9bbcffC3WugMWo69ZHrawRwPPxzvV8ha5knPV/FPa1zg6n HGyqmbiBdq/Ir0PyAxmIQxJUnTEm/Jyi5yzjg59HAo0PdLFX2MJJVOMRF4ieSDiV 2KkzmhSKOjXE+UlcwZvWEm9KX8zSVzLNdxik5PgJEZLbjLWFzq0fCxtruHhAErRM bct5kw14+pP9+XerY/Et1uv6mD/4ZKbSRzXB/7Mzv1pU21pLgYtBgSx7fQiV0weI C/gSk2KeMJUU9TzWPvYa =aGbz -----END PGP SIGNATURE----- --3siQDZowHQqNOShm--