Re: [Qemu-devel] IDs in QOM

[Markus Armbruster]

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:
>>>>
>>>> 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?
>
> -> Paolo ;)

Paolo?

>>>>> 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.
>
> We cannot use id_wellformed() in object_property_add(), as I assume it
> prohibits '.' as well, which we need for bus names.

It doesn't.

> This would be easier to discuss if you gave us the exact list of
> outlawed characters for comparison. ',' is probably another?

Quoting myself:

    QemuOpts IDs need to be well-formed: consist of letters, digits, '-',
    '.', '_', starting with a letter.  See id_wellformed(), commit b560a9a
    "qemu-option: Reject anti-social IDs".  This restriction has served us
    well.

We can discuss permitting more characters.

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