On Fri, Oct 30, 2020 at 09:41:46PM +0100, Paolo Bonzini wrote: > Il ven 30 ott 2020, 21:03 Eduardo Habkost <ehabk...@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.
Sounds good, and I like the "field property" name. It is more descriptive than "static property". -- Eduardo