* [Qemu-devel] qdev properties vs qom object properties @ 2017-06-05 13:10 Peter Maydell 2017-06-05 13:32 ` Paolo Bonzini 2017-06-05 13:36 ` Eduardo Habkost 0 siblings, 2 replies; 7+ messages in thread From: Peter Maydell @ 2017-06-05 13:10 UTC (permalink / raw) To: QEMU Developers Cc: Eduardo Habkost, Marc-André Lureau, Paolo Bonzini, Markus Armbruster I perpetually get confused about qdev properties vs QOM object properties. Why do we have both of these APIs? How do they interact? Which is the recommended one for new device code? Do we have a transition plan for old code? Where should I be looking for the documentation on this? For a specific example, I see that target/arm is the only code using qdev_property_add_static(), but there's no indication that the function is deprecated or what the right thing to be doing instead is. Any suggestions? thanks -- PMM ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-05 13:10 [Qemu-devel] qdev properties vs qom object properties Peter Maydell @ 2017-06-05 13:32 ` Paolo Bonzini 2017-06-05 13:39 ` Eduardo Habkost 2017-06-06 7:22 ` Markus Armbruster 2017-06-05 13:36 ` Eduardo Habkost 1 sibling, 2 replies; 7+ messages in thread From: Paolo Bonzini @ 2017-06-05 13:32 UTC (permalink / raw) To: Peter Maydell, QEMU Developers Cc: Eduardo Habkost, Marc-André Lureau, Markus Armbruster On 05/06/2017 15:10, Peter Maydell wrote: > I perpetually get confused about qdev properties vs QOM object > properties. > > Why do we have both of these APIs? > How do they interact? qdev properties are just a wrapper around QOM object properties, taking care of: - not allowing to set the property after realize - providing default values - letting people use the familiar DEFINE_PROP_* array syntax - pretty printing for "info qtree" (which right now is only used by PCI devfn and vlan properties) > Which is the recommended one for new device code? > Do we have a transition plan for old code? > Where should I be looking for the documentation on this? There is no transition plan, qdev properties are not going to go away soon unless someone actually makes a plan. Now that there are QOM class properties, it would actually be feasible to make qdev_property_add_static define QOM properties on the class rather than the object. In other words, instead of dc->props = virtio_serial_pci_properties; you'd have something like: qdev_add_class_properties(klass, usb_tablet_properties); or even inlined calls like the following: QDEV_DEFINE_CLASS_PROP_UINT32(klass, "usb_version", USBHIDState, usb_version, 2); QDEV_DEFINE_CLASS_PROP_STRING(klass, "display", USBHIDState, display); QDEV_DEFINE_CLASS_PROP_UINT32(klass, "head", USBHIDState, head, 0); > For a specific example, I see that target/arm is the only code > using qdev_property_add_static(), but there's no indication > that the function is deprecated or what the right thing to be > doing instead is. Any suggestions? The weird thing in ARM code is that the set of properties depends on the CPU model. That's the only reason why it uses qdev_property_add_static() as far as I can see. Paolo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-05 13:32 ` Paolo Bonzini @ 2017-06-05 13:39 ` Eduardo Habkost 2017-06-06 7:22 ` Markus Armbruster 1 sibling, 0 replies; 7+ messages in thread From: Eduardo Habkost @ 2017-06-05 13:39 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, QEMU Developers, Marc-André Lureau, Markus Armbruster On Mon, Jun 05, 2017 at 03:32:56PM +0200, Paolo Bonzini wrote: [...] > > Which is the recommended one for new device code? > > Do we have a transition plan for old code? > > Where should I be looking for the documentation on this? > > There is no transition plan, qdev properties are not going to go away > soon unless someone actually makes a plan. > > Now that there are QOM class properties, it would actually be feasible > to make qdev_property_add_static define QOM properties on the class > rather than the object. In other words, instead of > > dc->props = virtio_serial_pci_properties; > > you'd have something like: > > qdev_add_class_properties(klass, usb_tablet_properties); I have an old branch that does that. I don't remember if I submitted it to qemu-devel. I will try to rebase and (re)submit it. -- Eduardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-05 13:32 ` Paolo Bonzini 2017-06-05 13:39 ` Eduardo Habkost @ 2017-06-06 7:22 ` Markus Armbruster 2017-06-06 8:48 ` Gerd Hoffmann 1 sibling, 1 reply; 7+ messages in thread From: Markus Armbruster @ 2017-06-06 7:22 UTC (permalink / raw) To: Paolo Bonzini Cc: Peter Maydell, QEMU Developers, Marc-André Lureau, Eduardo Habkost Paolo Bonzini <pbonzini@redhat.com> writes: > On 05/06/2017 15:10, Peter Maydell wrote: >> I perpetually get confused about qdev properties vs QOM object >> properties. >> >> Why do we have both of these APIs? >> How do they interact? > > qdev properties are just a wrapper around QOM object properties, taking > care of: > > - not allowing to set the property after realize > > - providing default values > > - letting people use the familiar DEFINE_PROP_* array syntax It's not just familiar, it's also much easier to reason about, because it's *data*, not code. For instance, when I see DEFINE_PROP_UINT8(), I immediately know it's uint8_t. With QOM, I commonly have to figure out WTF the getter and setter will do at run time. I spent a few hours last week doing just that, and it sure feels like a severe case of OOPitis to me. Message-ID: <877f1ep4xv.fsf@dusky.pond.sub.org> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg04353.html > - pretty printing for "info qtree" (which right now is only used by PCI > devfn and vlan properties) > >> Which is the recommended one for new device code? >> Do we have a transition plan for old code? >> Where should I be looking for the documentation on this? > > There is no transition plan, qdev properties are not going to go away > soon unless someone actually makes a plan. Any plan to replace properties defined as data by properties defined in code will be a hard sell with me. I think we should go back to data unless the problem at hand *requires* code. > Now that there are QOM class properties, it would actually be feasible > to make qdev_property_add_static define QOM properties on the class > rather than the object. In other words, instead of > > dc->props = virtio_serial_pci_properties; > > you'd have something like: > > qdev_add_class_properties(klass, usb_tablet_properties); > > or even inlined calls like the following: > > QDEV_DEFINE_CLASS_PROP_UINT32(klass, "usb_version", USBHIDState, > usb_version, 2); > QDEV_DEFINE_CLASS_PROP_STRING(klass, "display", USBHIDState, > display); > QDEV_DEFINE_CLASS_PROP_UINT32(klass, "head", USBHIDState, head, 0); Sufficiently restricted code can be almost as simple as data. Still, why not make it data? Your examples scream to be data. >> For a specific example, I see that target/arm is the only code >> using qdev_property_add_static(), but there's no indication >> that the function is deprecated or what the right thing to be >> doing instead is. Any suggestions? > > The weird thing in ARM code is that the set of properties depends on the > CPU model. That's the only reason why it uses > qdev_property_add_static() as far as I can see. > > Paolo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-06 7:22 ` Markus Armbruster @ 2017-06-06 8:48 ` Gerd Hoffmann 0 siblings, 0 replies; 7+ messages in thread From: Gerd Hoffmann @ 2017-06-06 8:48 UTC (permalink / raw) To: Markus Armbruster, Paolo Bonzini Cc: Peter Maydell, QEMU Developers, Eduardo Habkost, Marc-André Lureau Hi, > Any plan to replace properties defined as data by properties defined > in > code will be a hard sell with me. I think we should go back to data > unless the problem at hand *requires* code. There *are* some cases which require code, specifically QOM properties which are writable after realize as they typically need some code to apply the changes. But, yes, the majority of properties we have in tree doesn't need that (realize callback will handle them) and qdev properties are a perfect fit for those. cheers, Gerd ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-05 13:10 [Qemu-devel] qdev properties vs qom object properties Peter Maydell 2017-06-05 13:32 ` Paolo Bonzini @ 2017-06-05 13:36 ` Eduardo Habkost 2017-06-05 13:44 ` Paolo Bonzini 1 sibling, 1 reply; 7+ messages in thread From: Eduardo Habkost @ 2017-06-05 13:36 UTC (permalink / raw) To: Peter Maydell Cc: QEMU Developers, Marc-André Lureau, Paolo Bonzini, Markus Armbruster On Mon, Jun 05, 2017 at 02:10:06PM +0100, Peter Maydell wrote: > I perpetually get confused about qdev properties vs QOM object > properties. You are not alone. :) > > Why do we have both of these APIs? I don't know. Probably because the QOM property API was introduced, it was just a subset of of the features provided by qdev properties, so the qdev API had to be kept. > How do they interact? qdev properties are implemented on top of the QOM property APIs. After the properties are registered by qdev code, we can simply use the QOM APIs to interact with them (to get/set/enumerate properties). But qdev provide some extra features[1], that's why we can't simply replace all code using qdev properties to use the QOM APIs directly. [1] Some of the differences I remember: * qdev properties can be defined declaratively using using Property arrays. * qdev properties allows you to set a default value more clearly in the code. * qdev properties don't require custom getters/setters to be written. You just need to provide the field name (which is saved as a field offset by the DEFINE_PROP_* macros). * qdev setters automatically check if "realized" is true, and refuse to change a property after the device is realized. * some existing code (mostly monitor code, I think) looks for qdev properties only, but will ignore other QOM properties. * A few data types (and their corresponding parsers) are only defined as qdev types (PropertyInfo structs), not on the QAPI schema. > Which is the recommended one for new device code? qdev properties are easier to use, so I recommend using them unless you need custom getters/setters. > Do we have a transition plan for old code? We don't. I believe we should first make the QOM API as powerful as the qdev property API. Then we can replace qdev-specific code with equivalent QOM code. > Where should I be looking for the documentation on this? Good question. The QOM API is well documented, but the way the qdev property code interacts with the QOM API is not. > > For a specific example, I see that target/arm is the only code > using qdev_property_add_static(), but there's no indication > that the function is deprecated or what the right thing to be > doing instead is. Any suggestions? qdev_property_static() is still easier to use than writing custom getters/setters for object_property_add(), so I don't think we should deprecate it yet. -- Eduardo ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] qdev properties vs qom object properties 2017-06-05 13:36 ` Eduardo Habkost @ 2017-06-05 13:44 ` Paolo Bonzini 0 siblings, 0 replies; 7+ messages in thread From: Paolo Bonzini @ 2017-06-05 13:44 UTC (permalink / raw) To: Eduardo Habkost, Peter Maydell Cc: QEMU Developers, Marc-André Lureau, Markus Armbruster On 05/06/2017 15:36, Eduardo Habkost wrote: > On Mon, Jun 05, 2017 at 02:10:06PM +0100, Peter Maydell wrote: >> Why do we have both of these APIs? > > I don't know. Probably because the QOM property API was > introduced, it was just a subset of of the features provided by > qdev properties, so the qdev API had to be kept. Indeed---especially there were no QOM class properties (and there are still no default values, which is the other place where we walk the props array). Paolo ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-06-06 8:48 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-05 13:10 [Qemu-devel] qdev properties vs qom object properties Peter Maydell 2017-06-05 13:32 ` Paolo Bonzini 2017-06-05 13:39 ` Eduardo Habkost 2017-06-06 7:22 ` Markus Armbruster 2017-06-06 8:48 ` Gerd Hoffmann 2017-06-05 13:36 ` Eduardo Habkost 2017-06-05 13:44 ` Paolo Bonzini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.