Re: [PATCH V4 3/7] qapi/net: Add new QMP command for COLO passthrough

[Markus Armbruster]

"Zhang, Chen" <chen.zhang@intel.com> writes:

>> -----Original Message-----
>> From: Qemu-devel <qemu-devel-
>> bounces+chen.zhang=intel.com@nongnu.org> On Behalf Of Markus
>> Armbruster
>> Sent: Tuesday, March 23, 2021 5:58 PM
>> To: Zhang, Chen <chen.zhang@intel.com>
>> Cc: Lukas Straub <lukasstraub2@web.de>; Li Zhijian
>> <lizhijian@cn.fujitsu.com>; Jason Wang <jasowang@redhat.com>; qemu-
>> dev <qemu-devel@nongnu.org>; Dr. David Alan Gilbert
>> <dgilbert@redhat.com>; Zhang Chen <zhangckid@gmail.com>
>> Subject: Re: [PATCH V4 3/7] qapi/net: Add new QMP command for COLO
>> passthrough
>> 
>> "Zhang, Chen" <chen.zhang@intel.com> writes:
>> 
>> >> -----Original Message-----
>> >> From: Markus Armbruster <armbru@redhat.com>
>> [...]
>> >> Now let's look at colo-passthrough-del.  I figure it is for deleting
>> >> the kind of things colo-passthrough-add adds.
>> >>
>> >
>> > Yes.
>> >
>> >> What exactly is deleted?  The thing created with the exact same
>> arguments?
>> >>
>> >
>> > Delete the rule from the module's private bypass list.
>> > When user input a rule, the colo-passthrough-del will find the
>> > specific module by the object ID, Then delete the rule.
>> >
>> >> This would be unusual.  Commonly, FOO-add and FOO-del both take a
>> >> string ID argument.  The FOO created by FOO-add remembers its ID, and
>> >> FOO-del deletes by ID.
>> >
>> > The ID not for rules itself, it just logged the modules(ID tagged) 
>> > affected by
>> the rule.
>> 
>> I'm not sure I understand.
>> 
>> If you're pointing out that existing colo-passthrough-del parameter @id is 
>> not
>> suitable for use as unique rule ID: you can always add another parameter
>> that is suitable.
>
> Sorry to missed this mail.
>
> For example:
> The VM running with filter-mirror(object id==0), filter-redirector(object 
> id==1) and colo-compare(object id==2),
> We use  colo-passthrough-add/del to add/del a rule with a ID, if the ID==2, 
> the rule just affect to colo-compare.
> The filter-mirror and filter-redirector feel nothing after the add/del.

I think you're trying to explain existing parameter @id.  The point I
was trying to make is unrelated to this parameter, except by name
collision.

My point is: our existing "delete" operations select the object to be
deleted by some unique name that is assigned by the "add" operation.
The unique name is a property of the object.  The property name is
often, but not always "id".

Examples:

    device_add argument "id" sets the device's unique name.
    device_del argument "id" selects the device to delete by its name.

    blockdev-add argument "node-name" sets the block backend device's
    unique name.
    blockdev-del argument "node-name" selects the block backend device
    to delete by its name.

Is there any particular reason why deletion of your kind of object can't
work the same way?