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