Re: [Qemu-devel] IDs in QOM

[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:
>> 
>> This discussion seems orthogonal to your patch.  But I'm not applying it
>> yet to give more time for discussion/review of the patch.
>> 
>>> 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?

>>> Backtracking a bit...  Unlike QMP object-add, -object ) and HMP
>>> object-add use QemuOpts.  See object_create(), commit 68d98d3 "vl: add
>>> -object option to create QOM objects from the command line", and
>>> hmp_object_add(), commit cff8b2c "monitor: add object-add (QMP) and
>>> object_add (HMP) command".  Parameter 'id' is the QemuOpts ID, thus
>>> bound by its well-formedness rule.
>>>
>>> Therefore, -object and HMP object-add only support a subset of the
>>> possible names.
>>>
>>> In particular, they do not permit "automatic arrayification".
>>>
>>> Should QOM names be (well-formed!) IDs?
>> 
>> Yes, I think that is sane.
>> 
>> Are there any invalid IDs used as QOM names today?
>> 
>> Hopefully the answer is no and we can lock everything down using
>> id_wellformed().
>
> On IRC I was arguing against that, preferring some more specific
> object_property_name_wellformed() or so. This could be called from
> object_property_add(), with invalid names returning an Error *.
>
> Only thing to check for would be '/'?

We obviously have to outlaw '/'.  However, unless we outlaw just like
id_wellformed():

>> If not, is -object and HMP object-add restricting the names to
>> well-formed IDs a bug?

Opinions?

My opinion is to stick to id_wellformed() and call it a day.