Andreas Färber <afaer...@suse.de> 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 <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.
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.
