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 <arm...@redhat.com> 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
signature.asc
Description: OpenPGP digital signature
