Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Feb 21, 2017 at 05:59:53PM +0000, Peter Maydell wrote:
> On 21 February 2017 at 16:18, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 21/02/2017 14:57, Peter Maydell wrote:
> >>> -global is a qdev thing.
> >> ...which reminds me to ask: is there any hope for unifying
> >> our properties so we don't have both "qdev properties" and
> >> "qom properties" or are we doomed to two distinct sets of
> >> APIs forever?
> >
> > We already have one set of property APIs in some sense.  qdev properties
> > *are* QOM properties; you visit them with object_property_foreach and so on.
> >
> > The extensions that qdev adds, and are exclusive to qdev properties, are
> > the following:
> >
> > - defining properties via DEFINE_PROPERTY_* (qdev_property_add_static etc.)
> >
> > - defining default values with -global (global_props and a handful of
> > functions that use it).
> 
> ...I didn't realize -global only worked on qdev properties.
> That's kind of awkward (but then -global syntax is awkward
> in any case). What's the QOM equivalent?

-global work on any kind of QOM properties (qdev properties are
registered as QOM properties). The only restriction is that it
works only on TYPE_DEVICE subclasses.

> 
> > - providing alternative human-readable formatting for info qtree
> > (qdev_property_add_legacy)
> 
> There's also a distinct set of functions for setting them:
> qdev_prop_set_uint32() vs object_property_set_int(), etc.
> These seem to be sometimes just wrappers (eg set_uint32), sometimes
> wrappers with a little convenience functionality (eg set_macaddr),
> and sometimes doing something more complex (eg set_enum, set_ptr).
> 
> The effect at the board code level is that code for creating,
> setting properties on and realizing qdev devices tends to look
> very different from that for doing so for plain QOM objects
> [qdev_create / qdev_prop_set* / qdev_init_nofail vs object_new /
> object_property_set_* / object_property_set_bool(... "realized" ...) ]
> 
> Can/should we just deprecate further use of the qdev_* APIs?

I don't think we can, until we provide a QOM API that is as
powerful and as easy to use as the DEFINE_PROP_* macros.

This probably isn't as hard as it sounds: I believe the only
thing forcing the existing DEFINE_PROP_* macros and PropertyInfo
structs to be qdev-specific is the device->realized check inside
the property setters.

-- 
Eduardo