qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 03/12] qom: Make object_class_property_add_uint*_ptr() get of


From: Eduardo Habkost
Subject: Re: [PATCH 03/12] qom: Make object_class_property_add_uint*_ptr() get offset
Date: Tue, 27 Oct 2020 18:18:42 -0400

On Fri, Oct 23, 2020 at 05:33:14PM +0200, Igor Mammedov wrote:
> On Wed, 21 Oct 2020 09:30:41 -0400
> Eduardo Habkost <ehabkost@redhat.com> wrote:
[...]
> > I don't love object*_property_add_*_ptr() either.  I consider the
> > qdev property API better.  But we need a reasonable alternative,
> > because the qdev API can't be used by non-device objects yet.
> > I don't think object*_property_add() and
> > object*_property_add_bool() are reasonable alternatives.
> 
> I also like old qdev API as it can be introspected (it's just data at
> class level), very concise when used and has default values.
> 
> Instead of duplicating all that pointer arithmetic from qdev properties
> in QOM API, it could be better to fix qdev properties so that they
> would work for Object as well.
> At least all that thrown away type safety would stay constrained/hidden
> inside of qdev property macros, instead of being opencoded (offsets) all
> over the place.
> 
> How hard it would be make qdev properties to work with Object and what
> makes you duplicate ugly part of it in QOM instead of making them to
> handle Object strait away?

It is doable, but lots of work.  I'm working on this right now.

> That would also result in huge removal of boiler plate of current QOM
> properties.

Yep.

> 
> That should suit your goal to make (most) properties introspectable
> and statically described.

That's correct.  I just don't want a huge qdev refactor to be a
reason to delay important work in other areas.

-- 
Eduardo




reply via email to

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