From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZhqh-0006QP-8N for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:59:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XZhqb-0006ja-AY for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:59:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XZhqb-0006jR-3a for qemu-devel@nongnu.org; Thu, 02 Oct 2014 10:59:13 -0400 From: Markus Armbruster References: <1412078370-3555-1-git-send-email-armbru@redhat.com> <87iok46kb8.fsf@blackfin.pond.sub.org> <20141002132119.GD30564@stefanha-thinkpad.redhat.com> <542D5284.1060201@suse.de> <87tx3mblhq.fsf@blackfin.pond.sub.org> <542D6127.7040308@suse.de> Date: Thu, 02 Oct 2014 16:59:05 +0200 In-Reply-To: <542D6127.7040308@suse.de> ("Andreas =?utf-8?Q?F=C3=A4rber=22?= =?utf-8?Q?'s?= message of "Thu, 02 Oct 2014 16:28:55 +0200") Message-ID: <87tx3ma56u.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] IDs in QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?utf-8?Q?F=C3=A4rber?= Cc: kwolf@redhat.com, peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org, stefanha@redhat.com, Paolo Bonzini Andreas F=C3=A4rber writes: > Am 02.10.2014 um 16:21 schrieb Markus Armbruster: >> Andreas F=C3=A4rber writes: >>=20 >>> 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 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. >>=20 >> 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 '/'? >>=20 >> We obviously have to outlaw '/'. However, unless we outlaw just like >> id_wellformed(): >>=20 >>>> If not, is -object and HMP object-add restricting the names to >>>> well-formed IDs a bug? >>=20 >> Opinions? >>=20 >> 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 Qem= uOpts) Date: Wed, 01 Oct 2014 14:33:47 +0200 Message-ID: <87iok46kb8.fsf@blackfin.pond.sub.org>