From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0W8b-000676-OO for qemu-devel@nongnu.org; Tue, 07 Jan 2014 07:52:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0W8S-0007HX-S1 for qemu-devel@nongnu.org; Tue, 07 Jan 2014 07:52:05 -0500 Received: from mail-ea0-x231.google.com ([2a00:1450:4013:c01::231]:55557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0W8S-0007HP-KN for qemu-devel@nongnu.org; Tue, 07 Jan 2014 07:51:56 -0500 Received: by mail-ea0-f177.google.com with SMTP id n15so188486ead.36 for ; Tue, 07 Jan 2014 04:51:55 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52CBF865.7090708@redhat.com> Date: Tue, 07 Jan 2014 13:51:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386694828-19786-1-git-send-email-pbonzini@redhat.com> <1386694828-19786-5-git-send-email-pbonzini@redhat.com> <52A756AF.7000309@redhat.com> <52A75A29.1030204@redhat.com> <20131216150254.75ef86f6@redhat.com> <87haa83pvz.fsf@blackfin.pond.sub.org> <20131219215332.11040.45527@loki> <87bnzoxaqu.fsf@blackfin.pond.sub.org> In-Reply-To: <87bnzoxaqu.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] monitor: add object-add (QMP) and object_add (HMP) command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org, Michael Roth , Luiz Capitulino , Anthony Liguori , imammedo@redhat.com, akong@redhat.com Il 07/01/2014 13:00, Markus Armbruster ha scritto: >> > >> > Is dumping static properties based on class name sufficient, or do we >> > need introspection for dynamic properties as well? (or are those not >> > exposed outside of qom-set?) > > Can't say whether introspection limited to static properties would be > useful, because I don't actually know how static and dynamic properties > are used. I think right now dynamic properties are used little-to-nothing. They are used by non-devices such as the RNG backends, and for links (which should replace PROP_PTR). > I challenged the need for dynamic properties in the early QOM days, > because they lead to dynamic schemata and complicate introspection, but > Anthony assured us we cannot do without them. Dynamic properties are the basis of the QOM tree *as it is implemented now*. Children are simply dynamic properties of type child, and they must be dynamic since the command-line influences the QOM tree. So I agree with Anthony that dynamic properties are fundamental to the way QOM is implemented. I'm not sure it is *necessary* for it to be implemented that way, but I don't have any code to show that another implementation would be simpler or better or even possible. I also agree with him that moving the qdev properties code up to Object is not the right way to proceed in order to have static properties. That code has support for legacy property types such as hexadecimal, that we need not have outside -device (i.e. if we can create devices one day with -object, you'll have to write 0x402 because 402 will always be interpreted as decimal). At the same time it does not support neither links nor the more flexible getters/setters that QOM allows. We probably would want this for QOM static properties. On the other hand I agree with a large subset of your idea, i.e. that devices should have a known schema for the subset of properties that can be set at initialization time. Furthermore, this schema should be introspectable. Anyhow, with so little use of dynamic properties (outside children), I believe no one can argue his position successfully with code rather than just theories. > > We could maybe introduce a QAPI 'built-in' > > such as 'ObjectProperties' that automatically does the query based on the > > now-special 'type' param and handles all the type-checking up-front. This > > would avoid an open-ended 'dict' type proliferating too much and provide > > infrastructure for introspection. > > I'm afraid I'm too ignorant to understand what you're proposing. I don't really understand that either. Paolo