Re: [Qemu-devel] IDs in QOM

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> 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 couldn't you have a separate name generator there as well?

QOM:
* object_property_add() takes a non-magical name argument
* object_gen_name() takes a base name and generates a stream of
  derived names suitable for object_property_add()

Memory:
* memory_region_init() takes a non-magical name argument
* memory_gen_name() takes a base name... you get the idea
  actually a wrapper around object_gen_name()

>> 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.

We've been doing (2) so far simply because we've never wasted a thought
on it!  Since we're wasting thoughts now: which one do we like better?

Based on experience, I'd rather not make "user-created"
vs. "system-created" a hard boundary.  Once a system-created funny name
has become ABI, we can't ever let the user create it.  One reason for me
to prefer (1).

>> 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.

And ugly :)

So the "automatic arrayification" convenience feature added a property
name restriction.  What makes us sure this is the last time we add name
restrictions?