All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhao Liu <zhao1.liu@intel.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Daniel P . Berrangé" <berrange@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	qemu-devel@nongnu.org, "Peter Maydell" <peter.maydell@linaro.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"BALATON Zoltan" <balaton@eik.bme.hu>,
	"Mark Cave-Ayland" <mark.caveayland@nutanix.com>,
	devel@lists.libvirt.org, "Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [RFC 01/10] qom: Rename ObjectPropertyFlags to ObjectPropertyAccessorFlags
Date: Tue, 6 Jan 2026 10:14:15 +0800	[thread overview]
Message-ID: <aVxv9zfg1S1CVNcW@intel.com> (raw)
In-Reply-To: <20260105132820.4a411827@imammedo-mac>

> > I'm not sure about this. Currently, these read/write flags are actually
> > specific to pointer properties (as showed by the changes in this patch,
> > which all involve object_property_add_*_ptr() / object_class_property_add_*_ptr()).
> > 
> > Other property types doesn't yet support flag parameters, so additional
> > interface modifications are still needed.
> > 
> > And for now other property types either need to explicitly specify get/set
> > accessors (e.g., object_property_add_bool()) or directly use the default
> > get/set methods (e.g., object_property_add_link()).
> > 
> > If we extend read/write flags to other property types, such as adding
> > "flags" argument to object_property_add_bool(), we must ensure the
> > OBJ_PROP_FLAG_READ flag align with "get" argument and OBJ_PROP_FLAG_WRITE
> > flag align with "set" parameters.
> 
> Ain't thouse accessors callbacks?
> /I mean to you still can check flags inside of generic object property code
> without touching setter/getter./

Ah, I see, the default flags is OBJ_PROP_FLAG_READWRITE and I can check
them before calling setter/getter.

> >This would introduces additional complexity.
> 
> it still might be woth considering to compare this series with alternative approach.

Yes, will try to reuse current ObjectPropertyFlags.

Thanks,
Zhao



  reply	other threads:[~2026-01-06  1:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02 17:04 [RFC 00/10] qom: Support marking object properties as deprecated Zhao Liu
2025-12-02 17:04 ` [RFC 01/10] qom: Rename ObjectPropertyFlags to ObjectPropertyAccessorFlags Zhao Liu
2026-01-02 12:12   ` Igor Mammedov
2026-01-05  7:54     ` Zhao Liu
2026-01-05 12:28       ` Igor Mammedov
2026-01-06  2:14         ` Zhao Liu [this message]
2025-12-02 17:04 ` [RFC 02/10] qom: Add basic object property deprecation hint support Zhao Liu
2026-01-02 12:06   ` Igor Mammedov
2026-01-05  9:06     ` Zhao Liu
2025-12-02 17:04 ` [RFC 03/10] qom: Check property deprecation flag for global property Zhao Liu
2025-12-02 17:04 ` [RFC 04/10] qom: Check property deprecation flag for properities from qdict Zhao Liu
2025-12-02 17:04 ` [RFC 05/10] system/vl: Check property deprecation flag for properities of accelerator Zhao Liu
2025-12-02 17:04 ` [RFC 06/10] qom/qom-hmp-cmd: Check property deprecation flag for "qom-set" command Zhao Liu
2025-12-02 17:04 ` [RFC 07/10] hw/core/qdev-properties: Allow to mark qdev property as deprecated Zhao Liu
2026-01-02 12:27   ` Igor Mammedov
2026-01-05  8:34     ` Zhao Liu
2025-12-02 17:05 ` [RFC 08/10] target/i386: Deprecate fill-mtrr-mask property Zhao Liu
2025-12-02 17:05 ` [RFC 09/10] target/i386: Deprecate cpuid-0xb property Zhao Liu
2025-12-02 17:05 ` [RFC 10/10] hw/intc/ioapic: Deprecate version property Zhao Liu

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=aVxv9zfg1S1CVNcW@intel.com \
    --to=zhao1.liu@intel.com \
    --cc=armbru@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=berrange@redhat.com \
    --cc=devel@lists.libvirt.org \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=mark.caveayland@nutanix.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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.