Il 07/10/2014 14:16, Markus Armbruster ha scritto: >> > 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()
I see what you mean; you could even reuse object_gen_name(). It looks sane, I guess one has to see a patch to judge if it also _is_ sane. :) > > > 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? User interfaces other than QOM have been doing (2) too. netdev-add and device-add have been doing (2) because they use QemuOpts under the hood. blockdev-add has been consciously doing (2) for node-name. chardev-add has been doing (1), and I'd argue that this is a bug in chardev-add. QOM has two families of operations. One is -object/object-add/object-del. This is a high-level operation that only works with specific QOM classes (those that implement UserCreatable) and only operate on a specific part of the QOM tree (/objects). The other is qom-get/qom-set. This is a low-level operation that can explore all of the QOM tree. It cannot _create_ new objects and properties, however, so the user cannot escape the naming sandbox that we put in place for him. I think it's fair to limit the high-level operations to the same id space, no matter if they're QemuOpts based or not. > 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). Anything that is outside /objects is "funny", not just anything that has weird characters in its name. The QOM API consists of "magic" object canonical paths and magic property names which, as far as I know, can be easily listed: * the aforementioned /machine.rtc-time that lets you detect missed RTC_CHANGE events * the /backend tree that includes info on the graphic consoles. Not sure if this is considered stable, but it's there. * /machine/peripheral/foo lets you peek at run-time properties of -device id=foo - virtio-ballon has a couple of run-time properties, whose status I am not certain of. Probably stable but undocumented. * /objects/bar lets you reconstruct the properties of -object id=bar - there are no such run-time properties with any promised stability. In other words, practically all of the QOM API is outside /objects. But not all hope is lost. Were we to provide user access to the creation of graphic consoles, we could preserve the /backend API via aliases and links. This way, anything that currently happens in /machine or /backend can tomorrow happen in /objects, without breaking backwards compatibility. Similarly, a QOMified block-backend could be either: * an object that QEMU creates for you when you give -device scsi-disk,id=disk,drive=foo. The canonical path could be something like /machine/peripheral/disk/drive-backend, with a link in /machine/peripheral/disk/backend. * an object that you create with -object block-backend,id=bar,blockdev=myimg and reference with -device scsi-disk,backend=bar. The canonical path would be of course /objects/bar, but the same link would exist in /machine/peripheral/disk/backend. In either case, you would be able to find the block-backend using the same QOM path and property. > So the "automatic arrayification" convenience feature added a property > name restriction. What makes us sure this is the last time we add name > restrictions? Nothing. However, does it matter, as long as the now-disallowed names were not possible at all in -object/object_add? Paolo
