qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to ac


From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH v3] monitor: allow object_del & device_del to accept QOM paths
Date: Tue, 1 Sep 2015 18:00:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0

Am 01.09.2015 um 17:58 schrieb 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.

That's besides the point: IDs can already be specified without this
patch. This patch is shoehorning QOM paths into an existing ID argument.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]