"Zhang, Chen" <chen.zh...@intel.com> writes:
>> -----Original Message-----
>> From: Qemu-devel <qemu-devel-
>> bounces+chen.zhang=intel....@nongnu.org> On Behalf Of Markus
>> Armbruster
>> Sent: Tuesday, March 23, 2021 5:58 PM
>> To: Zhang, Chen <chen.zh...@intel.com>
>> Cc: Lukas Straub <lukasstra...@web.de>; Li Zhijian
>> <lizhij...@cn.fujitsu.com>; Jason Wang <jasow...@redhat.com>; qemu-
>> dev <qemu-devel@nongnu.org>; Dr. David Alan Gilbert
>> <dgilb...@redhat.com>; Zhang Chen <zhangc...@gmail.com>
>> Subject: Re: [PATCH V4 3/7] qapi/net: Add new QMP command for COLO
>> passthrough
>>
>> "Zhang, Chen" <chen.zh...@intel.com> writes:
>>
>> >> -----Original Message-----
>> >> From: Markus Armbruster <arm...@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?
