Paolo Bonzini <pbonz...@redhat.com> writes: > On 02/05/2018 11:38, Markus Armbruster wrote: >>>>> It probably is not unless someone adds properties in realize() callback, >>>> Now work that into the doc comment, please :) >>> Are there any examples? >> There must be examples where instances of the same type have different >> properties, or else our design decision to create properties dynamically >> was inane. > > Buses for example create properties at runtime to link a parent to its > children. These properties are created when a child device appears; > this is different from creating properties in or the realize() callback, > or upon setting other properties. > > The purpose of this command is to tell people/tools what they can pass > to -device/-object/device_add/object_add, so the real question is > whether there are cases where it falls short of that purpose. > > If not,
Do we have to be certain? Or would "we don't think so" be enough? > maybe the wording for the .json file could be something like: > > Objects can create properties at runtime, for example to describe > links between different devices and/or objects. These properties > are not included in the output of this command. Not bad. In theory, objects can also create properties in response to non-default configuration, and these would also not be included. Objects could even create a property with the same name, but different type or description. Arguably capital-letter Bad Ideas, but nothing prevents such misuse. Since I'm in a generous mood, I'd rate the thing at Rusty API level 4 "Follow common convention and you'll get it right." https://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html https://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html If dynamic properties are really just for internal use, as you seem to suggest in Message-ID: <c1d40d88-1c80-2bbd-c28c-613b7fe8d...@redhat.com>, then we should've had the common sense to unambiguously separate them from the user-facing properties. Can we still do that?
