From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSSf-0001P5-0K for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:32:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RaSSW-0007hR-Pu for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:32:00 -0500 Received: from mail-yw0-f45.google.com ([209.85.213.45]:46513) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RaSSW-0007hJ-Gd for qemu-devel@nongnu.org; Tue, 13 Dec 2011 08:31:52 -0500 Received: by yhgg71 with SMTP id g71so421999yhg.4 for ; Tue, 13 Dec 2011 05:31:52 -0800 (PST) Message-ID: <4EE753C5.70207@codemonkey.ws> Date: Tue, 13 Dec 2011 07:31:49 -0600 From: Anthony Liguori 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> <4EE71A69.4070508@redhat.com> In-Reply-To: <4EE71A69.4070508@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Kevin Wolf Cc: Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Luiz Capitulino , Gerd Hoffman , Markus Armbruster On 12/13/2011 03:27 AM, Kevin Wolf wrote: > 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? In qdev today, the objects have no state reflecting properties. They properties refer to object state, but the objects have no knowledge of the properties themselves. > >> 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? The way I imagine this all working out is that a user creates does something like this: (qemu) device_add driver=pc,id=pc (qemu) qom_list /pc /pc /i440fx /ide /ide1 /drive[0] /net[0] /serial[0] > >> 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. There isn't one struct as bus properties get inherited, but I understand your point. The problem with "legacy" properties isn't how they're express, it's that the mix parsing with the property types. I have no problem with using DEFINE_ style properties and would expect that we would find a way to make the current properties have a string and non-string interface. > 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. If you look at my qom-next branch, the static structs are still there for 99%er devices. I have no immediate plans of removing them. Regards, Anthony Liguori > > Kevin >