All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"John Snow" <jsnow@redhat.com>
Subject: Re: [PATCH 03/12] qom: Make object_class_property_add_uint*_ptr() get offset
Date: Thu, 29 Oct 2020 08:56:34 -0400	[thread overview]
Message-ID: <20201029125634.GJ5733@habkost.net> (raw)
In-Reply-To: <6f5c3a13-6798-9d7d-e686-69d549366095@redhat.com>

On Wed, Oct 28, 2020 at 04:22:40PM +0100, Paolo Bonzini wrote:
> On 23/10/20 17:33, Igor Mammedov wrote:
> > On Wed, 21 Oct 2020 09:30:41 -0400
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> > 
> >> On Wed, Oct 21, 2020 at 02:24:08PM +0200, Igor Mammedov wrote:
> >>> On Fri,  9 Oct 2020 12:01:13 -0400
> >>> Eduardo Habkost <ehabkost@redhat.com> wrote:
> >>>   
> >>>> The existing object_class_property_add_uint*_ptr() functions are
> >>>> not very useful, because they need a pointer to the property
> >>>> value, which can't really be provided before the object is
> >>>> created.
> >>>>
> >>>> Replace the pointer parameter in those functions with a
> >>>> `ptrdiff_t offset` parameter.
> >>>>
> >>>> Include a uint8 class property in check-qom-proplist unit tests,
> >>>> to ensure the feature is working.  
> >>>
> >>>
> >>> Not sure I like approach, it's reinventing qdev pointer properties in QOM form.  
> >>
> >> Yes, and that's on purpose.  If we want to eventually merge the
> >> two competing APIs into a single one, we need to make them
> >> converge.
> >>
> >>> I had an impression that Paolo wanted qdev pointer properties be gone
> >>> and replaced by something like link properties.  
> >>
> >> This is completely unrelated to qdev pointer properties and link
> >> properties.  The properties that use object_property_add_uint*_ptr()
> >> today are not qdev pointer properties and will never be link
> >> properties.  They are just integer properties.
> 
> I think this series a step in the right direction, but please take more
> "inspiration" from link properties, which are done right.  In
> particular, properties should have an optional check function and be
> read-only unless the check function is there.
> 
> You can make the check function take an uint64_t for simplicity, so that
> all the check functions for uint properties have the same prototype.
> For example a single "property_check_uint_allow" function can allow
> setting the property (which is almost always wrong, but an easy cop out
> for this series).

A property check callback that needs the property value is a more
complex use case, and would require too much property-type-specific
boilerplate today.  I plan to address it, but not right now.

In my next series that makes static properties usable by any QOM
object, I will add a separate "allow_set" callback to the
internal QOM property API, which will not take the property value
as argument.  This would be enough for the dev->realized checks
that are currently in qdev.

Interestingly, there is only one link property check callback
function in the QEMU tree that actually cares about the property
value: isa_ipmi_bmc_check().  All other cases either don't care
about the property value at all (qdev_prop_allow_set_link_before_realize(),
object_property_allow_set_link()), or are being misused for
something other than property checking (xlnx_dp_set_dpdma()).

-- 
Eduardo



  parent reply	other threads:[~2020-10-29 12:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-09 16:01 [PATCH 00/12] qom: Make all -object types use only class properties Eduardo Habkost
2020-10-09 16:01 ` [PATCH 01/12] qom: Helpers for pointer properties Eduardo Habkost
2020-10-09 16:01 ` [PATCH 02/12] qom: Introduce PointerProperty struct Eduardo Habkost
2020-10-09 16:01 ` [PATCH 03/12] qom: Make object_class_property_add_uint*_ptr() get offset Eduardo Habkost
2020-10-09 17:24   ` Eric Blake
2020-10-09 17:31     ` Eduardo Habkost
2020-10-21 12:24   ` Igor Mammedov
2020-10-21 13:30     ` Eduardo Habkost
2020-10-22  5:06       ` Markus Armbruster
2020-10-22 21:34         ` Eduardo Habkost
2020-10-23 15:33       ` Igor Mammedov
2020-10-27 22:18         ` Eduardo Habkost
2020-10-28 15:22         ` Paolo Bonzini
2020-10-28 15:53           ` Igor Mammedov
2020-10-29 12:56           ` Eduardo Habkost [this message]
2020-10-29 13:37             ` Igor Mammedov
2020-10-09 16:01 ` [PATCH 04/12] sev: Use class properties Eduardo Habkost
2020-10-09 16:01 ` [PATCH 05/12] rng: " Eduardo Habkost
2020-10-09 16:01 ` [PATCH 06/12] can_host: " Eduardo Habkost
2020-10-12 14:52   ` Pavel Pisa
2020-10-09 16:01 ` [PATCH 07/12] colo: " Eduardo Habkost
2020-10-09 16:01 ` [PATCH 08/12] netfilter: Reorder functions Eduardo Habkost
2020-10-09 16:01 ` [PATCH 09/12] netfilter: Use class properties Eduardo Habkost
2020-10-09 16:01 ` [PATCH 10/12] input: " Eduardo Habkost
2020-10-13 12:54   ` Gerd Hoffmann
2020-10-09 16:01 ` [PATCH 11/12] [RFC] qom: Property lock mechanism Eduardo Habkost
2020-10-09 16:01 ` [PATCH 12/12] [RFC] qom: Lock properties of all TYPE_USER_CREATABLE types Eduardo Habkost
2020-10-09 21:31   ` [PATCH] check-qom-proplist: Don't register instance props for user-creatable type Eduardo Habkost

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201029125634.GJ5733@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.