Re: [Qemu-devel] IDs in QOM

[Paolo Bonzini <pbonzini@redhat.com>]

Il 07/10/2014 10:01, Markus Armbruster ha scritto:
> "Automatic arrayification" isn't about array-valued properties, it's a
> convenience feature for creating a bunch of properties with a common
> type, accessors and so forth, named in a peculiar way: "foo[0]",
> "foo[1]", ...
> 
> The feature saves the caller the trouble of generating the names.
> That's all there is to it.
> 
> Once created, QOM assumes no particular relation between the properties.
> 
> Weird: if you create a "foo[2]", then three "foo[*]", the three become
> "foo[0]", "foo[1]", "foo[3]".
> 
> Correct so far?
> 
> If yes, then I retract my "isn't this type matter" remark: it isn't,
> it's just a fancy way to generate names.

Exactly.  Regarding the "weird part", it is really a case of "if it
hurts, do not do it". :)  For example, most memory regions are created
at or before realize time, and live until the parent device is
hot-unplugged or QEMU exits.  Unattached devices are created statically
at or before machine creation, and live until they are hot-unplugged or
QEMU exits.

> However, I now have a different one: should we really bake fancy ways to
> generate names into object_property_add()?
> 
> Wouldn't having a separate name generator be cleaner?

Possibly, except this would propagate all the way through the APIs.  For
example, right now [*] is added automatically to MemoryRegion
properties, but this can change in the future since many MemoryRegions
do not need array-like names.  Then you would have two sets of
MemoryRegion creation APIs, one that array-ifies names and one that doesn't.

> Why is it a good idea have two separate restrictions on property names?
> A loser one that applies always (anything but '\0' and '/'), and a
> stricter one that applies sometimes (letters, digits, '-', '.', '_',
> starting with a letter).
> 
> If yes, how is "sometimes" defined?

It applies to objects created by the user (either in
/machine/peripheral, or in /objects).  Why the restriction?  For
-object, because creating the object involves QemuOpts.  You then have
two ways to satisfy the principle of least astonishment:

1) always use the same restriction when a user creates objects;

2) do not introduce restrictions when a user is not using QemuOpts.

We've been doing (2) so far; often it is just because QMP wrappers also
used QemuOpts, but not necessarily.  So object_add just does the same.

> Are -object and object_add the only ways to create children of /objects?

Yes (of course you could do that programmatically in C, but I don't see
why you should/would do that).

> Hmm, I'm afraid my working definition of the loser one is incorrect.
> It's actually "anything but '\0' and '/' not ending with '[*]'.

True.

Paolo