qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH v3 06/17] qdev: Allow device specification by qt


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH v3 06/17] qdev: Allow device specification by qtree path for device_del
Date: Fri, 28 May 2010 16:16:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Luiz Capitulino wrote:
> On Fri, 28 May 2010 00:19:48 +0200
> Jan Kiszka <address@hidden> wrote:
> 
>> Luiz Capitulino wrote:
>>> On Sun, 23 May 2010 12:59:19 +0200
>>> Jan Kiszka <address@hidden> wrote:
>>>
>>>> From: Jan Kiszka <address@hidden>
>>>>
>>>> Allow to specify the device to be removed via device_del not only by ID
>>>> but also by its full or abbreviated qtree path. For this purpose,
>>>> qdev_find is introduced which combines walking the qtree with searching
>>>> for device IDs if required.
>>>  [...]
>>>
>>>>  Arguments:
>>>>  
>>>> -- "id": the device's ID (json-string)
>>>> +- "path": the device's qtree path or unique ID (json-string)
>>>>  
>>>>  Example:
>>>>  
>>>> --> { "execute": "device_del", "arguments": { "id": "net1" } }
>>>> +-> { "execute": "device_del", "arguments": { "path": "net1" } }
>>>  Doesn't seem like a good change to me, besides being incompatible[1] we
>>> shouldn't overload arguments this way in QMP as overloading leads to
>>> interface degradation (harder to use, understand, maintain).
>> It's not overloaded, think of an ID as a (weak) symbolic link in the
>> qtree filesystem. The advantage of basing everything on top of full or
>> abbreviated qtree paths is that IDs are not always assigned, paths are.
> 
>  You mean there're cases where an ID is not assigned? I didn't know that,
> I thought they were always assigned, at least via QMP.

Yes, platform devices or anything else that is auto-instantiated does
not have an ID. Granted, you normally don't want or even can remove such
devices, but you can perfectly display them. And someone asked for
unifying the paths accepted by device_show and device_del.

> 
>  In any case, my main question here is that if this change really makes
> sense for QMP or if it's something for HMP where we can have features
> like tab completion.

I don't think QMP would suffer from having separate arguments for ID and
qtree paths. We just need a way to map them on the same for HMP, ie. we
need argument types that only show up in one of both domains.

> 
>>>  Maybe we could have both arguments as optional, but one must be passed.
>> This would at least require some way to keep the proposed unified path
>> specification for the human monitor (having separate arguments there is
>> really unhandy).
> 
>  Agreed, perhaps we have to decouple QMP and HMP in the way proposed by
> Anthony: the HMP should work by making QMP calls (IIUC).
> 
>  This way HMP can accept whatever arguments make sense for it, but then
> it should transform them in a QMP call.
> 
>  This is a long term project though.

But the changes I propose already take effect today. We need at least an
interim solution.

We could postpone the device_del HMP format change e.g., but that would
take away some usability and leave criticized inconsistency behind.

Hmm, or we could simply introduce optional .hmp_args_type and
.hmp_params. HMP would favor them when provided by a command, otherwise
fall back to the standard params. Doesn't sound awfully complex and
invasive.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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