[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model
From: |
Peter Maydell |
Subject: |
Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model |
Date: |
Tue, 21 Feb 2017 17:59:53 +0000 |
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?
> - 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?
thanks
-- PMM
- Re: [Qemu-ppc] [RFC 0/3] generalize parsing of cpu_model, (continued)
- Re: [Qemu-ppc] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/17
- Re: [Qemu-ppc] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/20
- Re: [Qemu-ppc] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/20
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Markus Armbruster, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Peter Maydell, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Markus Armbruster, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Eduardo Habkost, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Paolo Bonzini, 2017/02/21
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model,
Peter Maydell <=
- Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Eduardo Habkost, 2017/02/21
Re: [Qemu-ppc] [RFC 0/3] generalize parsing of cpu_model, Eduardo Habkost, 2017/02/21
Re: [Qemu-ppc] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model, Igor Mammedov, 2017/02/22