Re: [PATCH v2 01/12] qom/object.c: rename object_class_property_uint*_ptr() to object_class_static_property_uint*_ptr()

[Mark Cave-Ayland]

On 07/07/2026 13:05, Daniel P. Berrangé wrote:

On Fri, Jul 03, 2026 at 02:53:03PM +0100, Mark Cave-Ayland wrote:
This more accurately reflects that these properties are held within the class 
and
not the object.
Signed-off-by: Mark Cave-Ayland <mark.caveayl...@nutanix.com>
---
  include/qom/object.h |  8 ++++----
  hw/riscv/spike.c     |  5 +++--
  qom/object.c         | 28 ++++++++++++++++------------
  3 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/include/qom/object.h b/include/qom/object.h
index 11f55613fc..89c23d45ab 100644
--- a/include/qom/object.h
+++ b/include/qom/object.h
@@ -1956,7 +1956,7 @@ ObjectProperty *object_property_add_uint8_ptr(Object 
*obj, const char *name,
                                                const uint8_t *v,
                                                ObjectPropertyFlags flags);
  
-ObjectProperty *object_class_property_add_uint8_ptr(ObjectClass *klass,
+ObjectProperty *object_class_static_property_add_uint8_ptr(ObjectClass *klass,
                                           const char *name,
                                           const uint8_t *v,
                                           ObjectPropertyFlags flags);
@@ -1977,7 +1977,7 @@ ObjectProperty *object_property_add_uint16_ptr(Object 
*obj, const char *name,
                                      const uint16_t *v,
                                      ObjectPropertyFlags flags);
  
-ObjectProperty *object_class_property_add_uint16_ptr(ObjectClass *klass,
+ObjectProperty *object_class_static_property_add_uint16_ptr(ObjectClass *klass,
                                            const char *name,
                                            const uint16_t *v,
                                            ObjectPropertyFlags flags);
@@ -1998,7 +1998,7 @@ ObjectProperty *object_property_add_uint32_ptr(Object 
*obj, const char *name,
                                      const uint32_t *v,
                                      ObjectPropertyFlags flags);
  
-ObjectProperty *object_class_property_add_uint32_ptr(ObjectClass *klass,
+ObjectProperty *object_class_static_property_add_uint32_ptr(ObjectClass *klass,
                                            const char *name,
                                            const uint32_t *v,
                                            ObjectPropertyFlags flags);
@@ -2019,7 +2019,7 @@ ObjectProperty *object_property_add_uint64_ptr(Object 
*obj, const char *name,
                                      const uint64_t *v,
                                      ObjectPropertyFlags flags);
  
-ObjectProperty *object_class_property_add_uint64_ptr(ObjectClass *klass,
+ObjectProperty *object_class_static_property_add_uint64_ptr(ObjectClass *klass,
                                            const char *name,
                                            const uint64_t *v,
                                            ObjectPropertyFlags flags);
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index 9fde0faf39..630b65f569 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -278,8 +278,9 @@ static void spike_machine_class_init(ObjectClass *oc, const 
void *data)
      object_class_property_add_str(oc, "signature", NULL, spike_set_signature);
      object_class_property_set_description(oc, "signature",
                                            "File to write ACT test signature");
-    object_class_property_add_uint8_ptr(oc, "signature-granularity",
-                                        &line_size, OBJ_PROP_FLAG_WRITE);
+    object_class_static_property_add_uint8_ptr(oc, "signature-granularity",
+                                               &line_size,
+                                               OBJ_PROP_FLAG_WRITE);

When we have just one use of these "static property" API in the code base,
I wonder if we genuinely need these APIs ?

There are actually more uses in hw/acpi later on in the series: see 
patches 7, 9 and 12.

I wonder why "line_size" isn't merely a field in the machine class ?
External code ought to be able to fetch the current machine and read
a line_size struct field, surely ?

It certainly looks odd from here: one of things I wanted to discuss on 
the call was how to approach the conversion.

My current thinking is that the aim should be simply to convert 
everything as-is, and avoid attempting any refactorings or converting to 
a device class prop via device_class_set_props() if possible. Otherwise 
anyone attempting conversions will get stuck in the details of the 
individual devices, which I would argue is more the remit of maintainers.


ATB,

Mark.