Re: [Qemu-devel] IDs in QOM

[Markus Armbruster]

[Quoted material edited somewhat to provide better context]

Paolo Bonzini <address@hidden> writes:

> Il 02/10/2014 16:59, Markus Armbruster ha scritto:
>> Andreas Färber <address@hidden> writes:
>> 
>>> Am 02.10.2014 um 16:21 schrieb Markus Armbruster:
>>>> Andreas Färber <address@hidden> writes:
>>>>
>>>>> Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
>>>>>> On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
>>>>>>> Markus Armbruster <address@hidden> writes:
>>>>>>>
>>>>>>> Actually, "property names are arbitrary strings" has recently become
>>>>>>> untrue: commit 339659 "qom: Add automatic arrayification to
>>>>>>> object_property_add()" changed names to have embedded syntax.  A
>>>>>>> property name ending with "[*]" makes the property special.  Normal
>>>>>>> properties can be added just once, and an attempt to add it again is an
>>>>>>> error.  These special properties, however, can be added any number of
>>>>>>> times, and each time the name "[*]" is silently rewritten to "[N]",
>>>>>>> where N counts from 0.
[...]
>>>>>>> Is mangling array-ness into the name really a good idea?  Isn't this
>>>>>>> type matter, not name matter?
>>>>>>
>>>>>> I agree.  It's nasty to hack the array selector into the name and will
>>>>>> probably cause us pain down the line.
>>>>
>>>> Andreas?
>>>
>>> -> Paolo ;)
>> 
>> Paolo?
>
> Uhm, I had written an answer but Thunderbird ate it.  Oh well.
>
> I think foo[*] is not really a matter of typing, but a matter of
> grouping similar children.  It does not really matter if foo[1] is
> deleted while foo[2] still exists, and it does not really matter if the
> next object created will be foo[1] or foo[3].
>
> While we do not have any example, QOM could support true array
> properties, e.g. with type intList.
>
> Also note that while foo[*] was a generalization of MemoryRegion code,
> the same idea has also existed forever for devices.
> /machine/peripheral_anon and /machine/unattached do not currently use
> automatic array-ification via foo[*], but they could.

Let me try to paraphrase / further explain your view, to make sure I got
it.

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

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?

And yet another one: the special treatment of names ending with "[*]"
appears to be entirely undocumented!  Review fail.

>>> If you just want to call id_wellformed() for -object / object-add, I
>>> won't object to restricting it beyond the necessary, but it'll lead to
>>> two places doing validity checks for QOM.
>> 
>> id_wellformed() is *already* called for -object and HMP object-add.
>> That's exactly my point!
>> 
>> Please reread my explanation, and if it's insufficient, ask for
>> clarification.
>> 
>> Subject: IDs in QOM (was: [PATCH] util: Emancipate id_wellformed()
>> from QemuOpts)
>> Date: Wed, 01 Oct 2014 14:33:47 +0200
>> Message-ID: <address@hidden>
>
> I think it is okay to keep calling id_wellformed(), since it covers the
> QOM-specific constraint that slashes must be outlawed.  It just makes
> the children of /objects a bit more restricted in their naming, but that
> is harmless because object_del can only delete objects created with
> object_add.

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?

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

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