On Fri, 03 May 2013 16:58:44 +0200 Andreas Färber <afaerber@xxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 02.05.2013 21:48, schrieb Eric Blake: > > On 05/02/2013 01:43 PM, Eduardo Habkost wrote: > >>> > >>> As mentioned earlier I'd prefer to defer the property design > >>> rather than putting it lightly reviewed into 1.5 and living > >>> with some ABI. If libvirt urgently needs this info, this series > >>> needs to be reviewed and sorted out until the weekend (Hard > >>> Freeze on Monday). > >> > >> I consider it an important bugfix for the QEMU+libvirt stack. > >> The current libvirt behavior (checking CPUID directly; not using > >> the "enforce" flag; and having its own copy of each CPU model > >> definition) is unsafe and may break live-migration silently under > >> many circumstances. > > > > I agree that libvirt would very much like to have this in 1.5. How > > can I help in reviewing things? > > Apart from the usual QMP considerations that you will know much better > than me, I have two concerns here: > 1) Polluting the QOM namespace with this dump-all implementation for > libvirt and interfering with more fine-grained property getters/setters. I think feature-words could be replaced with fine-grained feature properties eventually. > 2) Basing its design on current code of which we are not sure yet how > it may evolve and having to live with that for ABI stability. > Like I said, I hadn't reviewed that part yet, so couldn't pick it up > on short notice. If we get it respun and reviewed today, I can (try > to) prepare a PULL on Sunday. > > On Igor's series (latest: v7 from Feb 25) I had more or less nack'ed > the attempt to introduce f-* properties due to Anthony asking for I don't recall it being nacked or any other way commented. > verbose QOM property names, so we're in need of a better name, likely > something with "feature" in it, similar to what is being proposed here. > I had also argued with Anthony that QOM's object_property_add_bool() > should allow us to create a container object for accessing features in > a more simple way, such as .../icc/child[0]/cpuid-features/foo rather > than f-foo or feature-foo or foo-feature to avoid the constant > repetition and an unreadable long list of CPU properties, but the > addition of an opaque to support this was turned down. what if FeatureWordArray inherits from Object? than it would be trivial to create /icc/child[0]/cpuid-features/ where "cpuid-features" will be FeatureWordArray and each feature it's child? > So it boils down to the questions of where do we want to expose which > information, how should it be structured and where does/will that > information come from. Thanks. > > Regards, > Andreas > > - -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.19 (GNU/Linux) > > iQIcBAEBAgAGBQJRg9CkAAoJEPou0S0+fgE/Mu8P/1FFoXTMawQ2o8np/cjOFEze > zv+MJ5DUKZK96PPNoZjsM8y0tmNZ8VT9q578AQuElQiA/AbOaUqEoqL/NB9i9Bqc > PBZw7KwgNkH8Mogw7izOmOybKZbshdin9uBxRugG+Xyg5Nk7oMYkTQV8PLHmAgRc > LxgeMAJHsPY9LXksCNUbZNblK//EQfP90e7v0fU+ys5xrlCFlCl1xRQd9Cw2QvHd > 7gECUSlwOlkHY32BFEn/epqay45uZqlECyGXDqrssg5htLM5McbzKCa1sgdQbuqp > HqsO3WdM6jBrse5EApxdoaYmz8Yhl6ls+YOQY+l3DjjhHNcDzxtIqbAK36ErBHFz > 9d+NTcXBlGrC0N0L7VZmwLihJ3bT/IIEP7ybLFN/QKHlz4H83pEGftbBpPipqrwq > NZWk7Z6IiOKptxNyBKOa04+2DJvlafgwjysfTf5bjEQ+WDTEeMoubIOZiG9bC1bm > WdqAC6JzQYTpjT3kqbfxGlV8328N3Z1qrVpRZOevkPHpotaaSDa5VVSCOvj6hdJZ > P4L2hq94bskumINJWHZxYEGvrB+6MJfOn73icNSpzyg+2sVw2QVfVAfbe0XfGFag > 2JO5sFbl0be8rOh6Y7b2uxltfI1RnGIBmemRQkjP6Z3mynLs7EYKqs8LwpHR0FMm > 3oSPrNXELr02m/9eGpsb > =tUDY > -----END PGP SIGNATURE----- -- Regards, Igor -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list