From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:43223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaOah-0001dY-VC for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:24:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaOag-0004fg-91 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:24:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37738) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaOaf-0004fP-K2 for qemu-devel@nongnu.org; Tue, 13 Dec 2011 04:24:01 -0500 Message-ID: <4EE71A69.4070508@redhat.com> Date: Tue, 13 Dec 2011 10:27:05 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1322857256-14951-1-git-send-email-aliguori@us.ibm.com> <1322857256-14951-16-git-send-email-aliguori@us.ibm.com> <4EE1F052.1020703@redhat.com> <4EE2085F.2060604@us.ibm.com> <4EE21579.8090404@redhat.com> <4EE21A48.1070701@codemonkey.ws> In-Reply-To: <4EE21A48.1070701@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 15/18] rtc: add a dynamic property for retrieving the date List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Gerd Hoffman , Markus Armbruster Am 09.12.2011 15:25, schrieb Anthony Liguori: > On 12/09/2011 08:04 AM, Kevin Wolf wrote: >> Am 09.12.2011 14:08, schrieb Anthony Liguori: >>> On 12/09/2011 05:26 AM, Kevin Wolf wrote: >>>> Am 02.12.2011 21:20, schrieb Anthony Liguori: >>>>> This really shows the power of dynamic object properties compared to qdev >>>>> static properties. >>>>> >>>>> This property represents a complex structure who's format is preserved over the >>>>> wire. This is enabled by visitors. >>>>> >>>>> It also shows an entirely synthetic property that is not tied to device state. >>>>> >>>>> Signed-off-by: Anthony Liguori >>>> >>>> There's one thing that I was hoping to find answered when I would have >>>> reviewed the whole series, but it hasn't happened: There is no doubt >>>> that dynamic properties (in the sense of being able to modify them after >>>> constructions) are a useful thing. But you also claim that class-based >>>> properties are not enough for QOM and that we need object-based ones, >>>> which is a requirement not immediately obvious to me. >>>> >>>> Can you provide some examples where we would explicitly need >>>> object-based properties? >>> >>> Sure. Any property that's dynamic needs to be object based. A good example >>> would be PCI slots. >>> >>> Today, we unconditionally advertise 32 slots in our ACPI tables. It could be >>> desirable to eventually make this configurable. So you can imagine where you >>> would have an 'slot-count' property and if that was set to 16, it would result >>> in 'slot[0]..slot[15]' being created. >>> >>> There are other good examples too. >> >> So is it mostly about variably sized arrays, which just happen to be >> considered independent properties in your approach? Or are there cases >> where a logically separate property may be there or missing depending on >> some condition, or possibly even that a new property is created during >> runtime? > > So there are three possibilities for properties: > > 1) Properties have no per-object state, and exist entirely within the classes. > This is what qdev does today. Not quite sure what you mean by per-object state. The properties are fields in the XyzState, so they certainly are per-object? > 2) Properties are defined in the class, but carry per-object state. > > 3) Properties are defined in the object and carry per-object state. > > We definitely can rule out (1). Stateful properties are needed to implement > links, composition, and just about anything interesting. > > Another way that (3) is useful is that it allows you to create container devices > that more or less model a PCB. That's how peripheral[-anon] is implemented and > I imagine that it will also be useful for implementing "machine" devices. What would this look like? The user creates new child/link properties on the board, and some more automatically created properties somehow describe the wiring between them? > Of course, you could find a way to special case this with (2) but that's why I > ended up going with (3). You can avoid having a lot of special cases this way. I'm not entirely convinced that we really need this, but on the other hand I don't feel strong enough about it to argue. Actually I think my real problem isn't about per-object properties (although they might add unnecessary complexity), but more about going away from the qdev style of things where you had _one_ struct definition that nicely described all of the properties in a central place. Instead, I'm seeing patches that spread property definitions all over the code. Now I understand that for dynamically created properties (like on your PCB) this is necessary and can't be avoided. For about 99% of the devices static definition of properties would be enough, though. So basically what I'm asking for is getting the static structs back for the 99% and have common code that parses them and calls the appropriate functions to actually the properties. The remaining 1% that creates/deletes properties during runtime and isn't covered can directly call whatever it needs. Kevin