From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42424) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbRcu-0006vr-Sa for qemu-devel@nongnu.org; Tue, 07 Oct 2014 06:04:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XbRcl-0007Vh-Rv for qemu-devel@nongnu.org; Tue, 07 Oct 2014 06:04:16 -0400 Received: from mail-wi0-x22d.google.com ([2a00:1450:400c:c05::22d]:49690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XbRcl-0007VP-I3 for qemu-devel@nongnu.org; Tue, 07 Oct 2014 06:04:07 -0400 Received: by mail-wi0-f173.google.com with SMTP id fb4so7294109wid.0 for ; Tue, 07 Oct 2014 03:04:06 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <5433BA8E.9070101@redhat.com> Date: Tue, 07 Oct 2014 12:03:58 +0200 From: Paolo Bonzini MIME-Version: 1.0 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> <87tx3ma56u.fsf@blackfin.pond.sub.org> <542D8E3C.6000207@redhat.com> <87k34c71gi.fsf@blackfin.pond.sub.org> In-Reply-To: <87k34c71gi.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] IDs in QOM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, stefanha@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Anthony Liguori , =?UTF-8?B?QW5kcmVhcyBGw6RyYmU=?= =?UTF-8?B?cg==?= Il 07/10/2014 10:01, Markus Armbruster ha scritto: > "Automatic arrayification" isn't about array-valued properties, it's a > convenience feature for creating a bunch of properties with a common > type, accessors and so forth, named in a peculiar way: "foo[0]", > "foo[1]", ... > > The feature saves the caller the trouble of generating the names. > That's all there is to it. > > Once created, QOM assumes no particular relation between the properties. > > Weird: if you create a "foo[2]", then three "foo[*]", the three become > "foo[0]", "foo[1]", "foo[3]". > > Correct so far? > > If yes, then I retract my "isn't this type matter" remark: it isn't, > it's just a fancy way to generate names. Exactly. Regarding the "weird part", it is really a case of "if it hurts, do not do it". :) For example, most memory regions are created at or before realize time, and live until the parent device is hot-unplugged or QEMU exits. Unattached devices are created statically at or before machine creation, and live until they are hot-unplugged or QEMU exits. > However, I now have a different one: should we really bake fancy ways to > generate names into object_property_add()? > > Wouldn't having a separate name generator be cleaner? Possibly, except this would propagate all the way through the APIs. For example, right now [*] is added automatically to MemoryRegion properties, but this can change in the future since many MemoryRegions do not need array-like names. Then you would have two sets of MemoryRegion creation APIs, one that array-ifies names and one that doesn't. > Why is it a good idea have two separate restrictions on property names? > A loser one that applies always (anything but '\0' and '/'), and a > stricter one that applies sometimes (letters, digits, '-', '.', '_', > starting with a letter). > > If yes, how is "sometimes" defined? It applies to objects created by the user (either in /machine/peripheral, or in /objects). Why the restriction? For -object, because creating the object involves QemuOpts. You then have two ways to satisfy the principle of least astonishment: 1) always use the same restriction when a user creates objects; 2) do not introduce restrictions when a user is not using QemuOpts. We've been doing (2) so far; often it is just because QMP wrappers also used QemuOpts, but not necessarily. So object_add just does the same. > Are -object and object_add the only ways to create children of /objects? Yes (of course you could do that programmatically in C, but I don't see why you should/would do that). > Hmm, I'm afraid my working definition of the loser one is incorrect. > It's actually "anything but '\0' and '/' not ending with '[*]'. True. Paolo