[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eduardo Habkost
Subject: Re: [Qemu-arm] [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model
Date: Tue, 21 Feb 2017 15:21:44 -0300
User-agent: Mutt/1.7.1 (2016-10-04)

On Tue, Feb 21, 2017 at 04:48:49PM +0100, Markus Armbruster wrote:
> Peter Maydell <address@hidden> writes:
> > On 21 February 2017 at 13:56, Markus Armbruster <address@hidden> 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?
> Good question!  Paolo, Andreas, any ideas?

qdev properties are supposed to be just wrappers to easily add
QOM properties.

...in theory.

The current obstacles I see are:
1) the qdev static property macros (DEFINE_PROP_*) are very
   simple to use, and QOM property registration requires lots of
   boilerplate code;
2) The set of data types supported by the qdev macros doesn't
   seem to be a subset of the data types supported by QOM
3) qdev properties have the extra check for dev->realized on the
   setter functions.

If we make QOM properties as powerful and easy to use as the qdev
property system, replacing qdev properties with equivalent QOM
counterparts would be straightforward. The exact path we should
follow to do that is not clear to me, but cleanups going in that
direction would be welcome.

Some things I have considered, which may or may not be good
* Getting rid of PropertyInfo structs that can't be represented
  by QAPI types (e.g. qdev_prop_ptr).
* Generating PropertyInfo structs for primitive types using QAPI.
* Providing DEFINE_PROP_* macros for QOM, and make the qdev ones
  just wrappers around the QOM macros.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]