[Qemu-devel] Re: [PATCH v3 06/17] qdev: Allow device specification by qtree path for device_del

[Luiz Capitulino]

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.

 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.

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