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
