On Fri, Feb 07, 2014 at 11:55:25AM +0100, Paolo Bonzini wrote: > Il 07/02/2014 11:16, Eduardo Habkost ha scritto: > >You are not alone. I remember we spent lots of time trying to convince > >Anthony to allow global properties and compat_props affect dynamic > >properties not just static properties, and static properties were a big > >deal due to reasons I didn't understand completely. Now I am hearing the > >opposite message, and I don't understand the reasons for the change of > >plans. I am confused. > > Picture me confused as well, but at the same I think I understand > the reasons for the change of plans. > > At some point you have to acknowledge that the grand vision of QEMU > as a small core and management only poking at QOM objects with > properties has never materialized, and probably never will. > > After seeing no progress whatsoever on > http://wiki.qemu.org/Features/QOM#TODO after 2 years, we should > perhaps try to get fresh ideas into QOM based on how we've been > using it and what we'd like to do with it. "Design by committee" > (more accurately: "design by prophet") will not lead us anywhere. > > QOM definitely needs dynamic properties for child<>, and for tricks > such as simulation of array properties. However, assume Igor or > Eduardo or Marcel can come up with a new QAPI-friendly static > properties design, that combines the best feature of QOM dynamic > properties and qdev static properties, why should it be rejected? > > Code should not be frozen against some abstract design, it must > evolve to solve concrete problems until it can solve all of them > easily. Or do we want to become a project where good code is not > anymore the best way to have other developers change their mind? Also, I don't see the point in deprecating and rejecting code that use something which: * Is used ~230 times, in ~180 different source files in QEMU; * Is useful; * Doesn't have a replacement yet. Currently, static properties are useful, facilitate analyzing the code before compile time, facilitate exposing class information through QMP (with the existing "device-list-properties" command), and is better than requiring objects to be created just to find out which properties are available. It may replaced by something better in the future, but that's what we have today. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list