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

[Programmingkid]

On Sep 1, 2015, at 11:55 AM, Eric Blake wrote:

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

Don't forget having a really long command to type up just to find out
what qom path you need. 

Also the qom path itself is very long. A simple ID is much easier to type out.

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