| Message ID | 1322857256-14951-16-git-send-email-aliguori@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
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 <aliguori@us.ibm.com> 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? Kevin
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<aliguori@us.ibm.com> > > 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. Regards, Anthony Liguori > > Kevin >
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<aliguori@us.ibm.com> >> >> 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? Kevin
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<aliguori@us.ibm.com> >>> >>> 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. 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. 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. Regards, Anthony Liguori > > Kevin >
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<aliguori@us.ibm.com> >>>> >>>> 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
Hi, > 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. Fully agree. I guess we can even generate those structs in many cases. We will parse the ${device}State structs anyway for visitor-based vmstate, so with some extra declaration we can generate property descriptions too. For example this ... static PCIDeviceInfo intel_hda_info = { .qdev.name = "intel-hda", [ ... ] .qdev.props = (Property[]) { DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0), DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1), DEFINE_PROP_END_OF_LIST(), } }; ... could be just ... struct IntelHDAState { [ ... ] /* properties */ uint32_t debug __property(0); uint32_t msi __property(1); }; cheers, Gerd
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<aliguori@us.ibm.com> >>>>> >>>>> 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 >
On 12/13/2011 03:48 AM, Gerd Hoffmann wrote: > Hi, > >> 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. > > Fully agree. I guess we can even generate those structs in many cases. > We will parse the ${device}State structs anyway for visitor-based > vmstate, so with some extra declaration we can generate property > descriptions too. For example this ... > > static PCIDeviceInfo intel_hda_info = { > .qdev.name = "intel-hda", > [ ... ] > .qdev.props = (Property[]) { > DEFINE_PROP_UINT32("debug", IntelHDAState, debug, 0), > DEFINE_PROP_UINT32("msi", IntelHDAState, msi, 1), > DEFINE_PROP_END_OF_LIST(), > } > }; > > ... could be just ... > > struct IntelHDAState { > [ ... ] > /* properties */ > uint32_t debug __property(0); > uint32_t msi __property(1); > }; Yup, that's where I want to go. In qom-next, I've started splitting header files out specifically so we can do stuff like this. There's quite a bit of work to do before we can really start exploring here but I think it's not that much work to get the pc device models cleaned up such that we could run qc against the headers. Regards, Anthony Liguori > > cheers, > Gerd > >
Am 13.12.2011 14:31, schrieb Anthony Liguori: > 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<aliguori@us.ibm.com> >>>>>> >>>>>> 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. You mean that an object doesn't have access to the property metadata? Or what else would an object want to know about them? >>> 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] So you instantiated an object of the class pc, right? Which of the properties qom_list shows is per-object rather than per-class? >>> 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. Right, when looking at your serial examples, I saw that there are actually some of them left. This first series doesn't have any of them. I think the pattern may be that it's only children and links that are spread across the code and "primitive types" generally still use the declarative approach. Is there a reason not to include children/links there as well? I also think in the serial example there was quite some boilerplate code related to such things, that could probably be common code for most devices that can be described statically in tables. But I think I'll get to that once you post these patches, maybe I'll understand the reasons better by then. Kevin
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c index 2aaca2f..0c23cb0 100644 --- a/hw/mc146818rtc.c +++ b/hw/mc146818rtc.c @@ -614,6 +614,29 @@ static const MemoryRegionOps cmos_ops = { .old_portio = cmos_portio }; +// FIXME add int32 visitor +static void visit_type_int32(Visitor *v, int *value, const char *name, Error **errp) +{ + int64_t val = *value; + visit_type_int(v, &val, name, errp); +} + +static void rtc_get_date(DeviceState *dev, Visitor *v, void *opaque, + const char *name, Error **errp) +{ + ISADevice *isa = DO_UPCAST(ISADevice, qdev, dev); + RTCState *s = DO_UPCAST(RTCState, dev, isa); + + visit_start_struct(v, NULL, "struct tm", name, 0, errp); + visit_type_int32(v, &s->current_tm.tm_year, "tm_year", errp); + visit_type_int32(v, &s->current_tm.tm_mon, "tm_mon", errp); + visit_type_int32(v, &s->current_tm.tm_mday, "tm_mday", errp); + visit_type_int32(v, &s->current_tm.tm_hour, "tm_hour", errp); + visit_type_int32(v, &s->current_tm.tm_min, "tm_min", errp); + visit_type_int32(v, &s->current_tm.tm_sec, "tm_sec", errp); + visit_end_struct(v, errp); +} + static int rtc_initfn(ISADevice *dev) { RTCState *s = DO_UPCAST(RTCState, dev, dev); @@ -647,6 +670,10 @@ static int rtc_initfn(ISADevice *dev) qdev_set_legacy_instance_id(&dev->qdev, base, 2); qemu_register_reset(rtc_reset, s); + + qdev_property_add(&s->dev.qdev, "date", "struct tm", + rtc_get_date, NULL, NULL, s, NULL); + return 0; }
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 <aliguori@us.ibm.com> --- hw/mc146818rtc.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)