[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model |
Date: |
Tue, 21 Feb 2017 15:41:19 -0300 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Tue, Feb 21, 2017 at 05:59:53PM +0000, Peter Maydell wrote:
> On 21 February 2017 at 16:18, Paolo Bonzini <address@hidden> 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
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, (continued)
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/20
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/20
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Markus Armbruster, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Markus Armbruster, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Eduardo Habkost, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Paolo Bonzini, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model,
Eduardo Habkost <=
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Eduardo Habkost, 2017/02/21
- Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/22