Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to accept QOM paths

[Eric Blake]

On 09/01/2015 07:23 AM, Daniel P. Berrange wrote:

>>> +Remove device @var{id}. @var{id} may be a short ID
>>> +or a QOM object path.
>>
>> Have you considered using two alternative parameters, id and qom-path?
>> (qom_path was used elsewhere)
> 
> I'm not fussed either way, but I thought it simpler to not try to change
> the accepted parameters of the existing commands.  Looking, the only
> place I notice that uses a 'qom_path' is the return data in the CpuInfo
> struct.
> 
> Does anyone have strong feelings either way about use of id for both vs
> qom-path or id ?

Reusing 'id':
- Pros
  - less complicated interface (don't have to check for mutual exclusion)
- Cons
  - not introspectible (can't tell by introspection alone whether id can
take a QOM path)
  - confusing name (but not the first time we've had that issue)

Adding 'qom-path':
- Pros
  - introspectible
  - JSON expresses everything (we don't have to parse the first
character of the string to know which style was meant, as the choice of
key already decided it)
- Cons
  - Have to implement mutual exclusion ourselves (can't take 'id' and
'qom-path' at the same time, and at least one must be specified), unless
we invent a new way for qapi to express mutual exclusion (there are
other existing commands that would benefit from such an extension)

How likely is libvirt to need to introspect whether this extension is
available?  We've already argued that libvirt should already be giving
everything an id, and therefore, the existing semantics of 'id' are
already sufficient for libvirt's needs, and libvirt will never need to
delete by qom-path, and thus does not need to introspect whether
qom-path even works.

Therefore, I'm leaning towards simplicity rather than introspection; and
the patch is fine as-is from my viewpoint.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature