On Wed, Jun 17, 2026 at 09:25:27AM -0300, Fabiano Rosas wrote: > Peter Xu <[email protected]> writes: > > > On Thu, Jun 11, 2026 at 03:40:29PM +0100, Daniel P. Berrangé wrote: > >> There's nothing standard in QOM, but in patch 10 in this series > >> Peter has a DEFINE_TLS_PROP_HELPERS() which macro-ized the > >> repetitive getters/setters for the TLS string properties. The > >> duplicate code still exists in the binary of course, just hidden > >> from the source. > > > > I believe we have the standard, which is qdev-properties.. which is (1) > > class properties, (2) allow variable bindings so no setter/getter needed, > > remembering them with pointer offsets. > > > > It goes back to last version where the question becomes: whether we want to > > make qdev-properties to be official QOM API, by removing qdev specific > > changes and move them over to qom/. Then make qdev only add its special > > things on top. > > > > Said that, considering if we want to make all things qom-set-able to > > migration in the future, another option is directly go with getter/setter > > that will do the property checks one by one. One benefit of that is we can > > then get rid of migrate_params_check() and migrate_caps_check() altogether. > > > > Maybe I should go with the latter, and forget qdev? > > I think it's a good idea. For caps that depend on one another do you > intend to check once in each setter? The _check functions exist is > because we want to validate the total state of params/caps, not just a > single param. Just pointing it out, it's not necessarily an issue.
The user-creatable interface has a "complete" method which is called once all props have been set. So if there are semantics you can't validate against individual props in isolation, you can leave that validation until "complete". With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
