qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] IDs in QOM


From: Andreas Färber
Subject: Re: [Qemu-devel] IDs in QOM
Date: Thu, 02 Oct 2014 15:26:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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.
> 
>> 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 '/'?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]