Re: [Qemu-devel] IDs in QOM

[Kevin Wolf <kwolf@redhat.com>]

Am 07.10.2014 um 17:14 hat Paolo Bonzini geschrieben:
> 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.

Is there any way to add netdevs/chardevs/devices in a non-QemuOpts way?
If not, (1) and (2) are the same thing, and the checks are always
applied.

I think always checking for the same allowed set of characters is the
only sane way to do things. Otherwise you end up with names that can be
used in one place, but not in another, e.g. you can create an object,
but then not delete it again using HMP. Or you can use a name for
hotplug, but not on the initial startup when the command line
configures the device. That's definitely something to be avoided.

> > 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?

They were possible in QMP object-add, weren't they?

Kevin