Paolo Bonzini <pbonz...@redhat.com> writes: > 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 couldn't you have a separate name generator there as well? QOM: * object_property_add() takes a non-magical name argument * object_gen_name() takes a base name and generates a stream of derived names suitable for object_property_add() Memory: * memory_region_init() takes a non-magical name argument * memory_gen_name() takes a base name... you get the idea actually a wrapper around object_gen_name() >> 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. We've been doing (2) so far simply because we've never wasted a thought on it! Since we're wasting thoughts now: which one do we like better? Based on experience, I'd rather not make "user-created" vs. "system-created" a hard boundary. Once a system-created funny name has become ABI, we can't ever let the user create it. One reason for me to prefer (1). >> 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. And ugly :) So the "automatic arrayification" convenience feature added a property name restriction. What makes us sure this is the last time we add name restrictions?
