qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 34/36] machine: Use DEFINE_PROP_STRING for string properties


From: Paolo Bonzini
Subject: Re: [PATCH 34/36] machine: Use DEFINE_PROP_STRING for string properties
Date: Fri, 30 Oct 2020 21:41:46 +0100



Il ven 30 ott 2020, 21:03 Eduardo Habkost <ehabkost@redhat.com> ha scritto:
>     OBJECT_CLASS_PROPERTY_ADD_STR(oc, MachineState, kernel_filename,
>                                   "kernel", prop_allow_set_always);

I like the idea of having an interface like this, but I would
like to avoid having to write even more boilerplate for each
property type to make this work.

What would you think of:
   OBJECT_CLASS_PROPERTY_ADD(oc,
       PROP_STRING("kernel", MachineState, kernel_filename),
       prop_allow_set_always);

Then we could make the same PROP_STRING macro usable both as
object_class_property_add_static() argument and as initializer
for existing static Property arrays.

The name should be an argument to OBJECT_CLASS_PROPERTY_ADD though (which could be a function and not  macro; perhaps object_class_property_add_field?). PROP_STRING would be DEFINE_PROP_STRING(NULL, etc.) and would not be entirely reusable in Property arrays.

But even with that snag I agree with your less-boilerplate argument against my proposal.

Since most if not all device properties would have to specify the same allow-set function, we would end up defining more macros DEVICE_CLASS_PROPERTY_ADD_STR, and so on. If the Property isbpassed a struct, instead, we can define just one wrapper device_class_property_add_field.

So what about:

1) add new constructors without the DEFINE prefix and without the name argument

2) add object_class_property_add_field

And later:

3) add device_class_property_add_field and remove dc->props

4) remove the name field from Property.

Paolo


--
Eduardo


reply via email to

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