Amos Kong <ak...@redhat.com> writes:
> netclient 'name' entry in event is useful for management to know
> which device is changed. n->netclient_name is not always set.
> This patch changes to use nc->name. If we don't assign 'id',
> qemu will set a generated name to nc->name.
>
> Signed-off-by: Amos Kong <ak...@redhat.com>
> ---
> hw/net/virtio-net.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index c88403a..e4d9752 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -200,14 +200,9 @@ static void rxfilter_notify(NetClientState *nc)
> VirtIONet *n = qemu_get_nic_opaque(nc);
>
> if (nc->rxfilter_notify_enabled) {
> - if (n->netclient_name) {
> - event_data = qobject_from_jsonf("{ 'name': %s, 'path': %s }",
> - n->netclient_name,
> -
> object_get_canonical_path(OBJECT(n->qdev)));
> - } else {
> - event_data = qobject_from_jsonf("{ 'path': %s }",
> -
> object_get_canonical_path(OBJECT(n->qdev)));
> - }
> + event_data = qobject_from_jsonf("{ 'name': %s, 'path': %s }",
> + nc->name,
> + object_get_canonical_path(OBJECT(n->qdev)));
> monitor_protocol_event(QEVENT_NIC_RX_FILTER_CHANGED, event_data);
> qobject_decref(event_data);
Is this on top of "[PATCH v3 0/2] mac programming over macvtap"?
Yes, qdev IDs are optional, and therefore can serve as reliable
identifier only when the user / management application always specifies
one, and even then, you're still screwed for auto-created devices.
Easily avoided for NICs, but yes, the problem is real.
However, I don't agree with the solution "use NetCientState name",
because that's too ad hoc, and not general. Can we please use QOM
paths?
