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
