Patchwork [v2,2/2] net: Dump client type 'info network'

login
register
mail settings
Submitter Jan Kiszka
Date May 20, 2011, 4:19 p.m.
Message ID <4DD694A9.2070209@siemens.com>
Download mbox | patch
Permalink /patch/96644/
State New
Headers show

Comments

Jan Kiszka - May 20, 2011, 4:19 p.m.
Include the client type name into the output of 'info network'. The
result looks like this:

(qemu) info network
VLAN 0 devices:
  rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
Devices not on any VLAN:
  virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
   \ network1: type=tap,fd=5

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

Changes in v2:
 - format type as "type=name"
 - use standard type names
 - factor out print_net_client

 net.c |   25 ++++++++++++++++++++++---
 1 files changed, 22 insertions(+), 3 deletions(-)
Markus Armbruster - May 23, 2011, 9:28 a.m.
Jan Kiszka <jan.kiszka@siemens.com> writes:

> Include the client type name into the output of 'info network'. The
> result looks like this:
>
> (qemu) info network
> VLAN 0 devices:
>   rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
> Devices not on any VLAN:
>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>    \ network1: type=tap,fd=5
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>
> Changes in v2:
>  - format type as "type=name"
>  - use standard type names
>  - factor out print_net_client
>
>  net.c |   25 ++++++++++++++++++++++---
>  1 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/net.c b/net.c
> index 606ce70..6d06eb7 100644
> --- a/net.c
> +++ b/net.c
> @@ -1221,6 +1221,22 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
>      return 0;
>  }
>  
> +static void print_net_client(Monitor *mon, VLANClientState *vc)
> +{
> +    static const char *typename[] = {
> +        [NET_CLIENT_TYPE_NONE]   = "none",
> +        [NET_CLIENT_TYPE_NIC]    = "nic",
> +        [NET_CLIENT_TYPE_SLIRP]  = "user",
> +        [NET_CLIENT_TYPE_TAP]    = "tap",
> +        [NET_CLIENT_TYPE_SOCKET] = "socket",
> +        [NET_CLIENT_TYPE_VDE]    = "vde",
> +        [NET_CLIENT_TYPE_DUMP]   = "dump",
> +    };
> +
> +    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
> +                   typename[vc->info->type], vc->info_str);
> +}

Any particular reason for using typename[vc->info->type] instead of
net_client[types[vc->info->type].type?

[...]
Jan Kiszka - May 23, 2011, 9:32 a.m.
On 2011-05-23 11:28, Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> Include the client type name into the output of 'info network'. The
>> result looks like this:
>>
>> (qemu) info network
>> VLAN 0 devices:
>>   rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
>> Devices not on any VLAN:
>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>    \ network1: type=tap,fd=5
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> Changes in v2:
>>  - format type as "type=name"
>>  - use standard type names
>>  - factor out print_net_client
>>
>>  net.c |   25 ++++++++++++++++++++++---
>>  1 files changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/net.c b/net.c
>> index 606ce70..6d06eb7 100644
>> --- a/net.c
>> +++ b/net.c
>> @@ -1221,6 +1221,22 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
>>      return 0;
>>  }
>>  
>> +static void print_net_client(Monitor *mon, VLANClientState *vc)
>> +{
>> +    static const char *typename[] = {
>> +        [NET_CLIENT_TYPE_NONE]   = "none",
>> +        [NET_CLIENT_TYPE_NIC]    = "nic",
>> +        [NET_CLIENT_TYPE_SLIRP]  = "user",
>> +        [NET_CLIENT_TYPE_TAP]    = "tap",
>> +        [NET_CLIENT_TYPE_SOCKET] = "socket",
>> +        [NET_CLIENT_TYPE_VDE]    = "vde",
>> +        [NET_CLIENT_TYPE_DUMP]   = "dump",
>> +    };
>> +
>> +    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
>> +                   typename[vc->info->type], vc->info_str);
>> +}
> 
> Any particular reason for using typename[vc->info->type] instead of
> net_client[types[vc->info->type].type?

Uncertainty about the sorting of that array. Is it supposed to be
aligned to NET_CLIENT_TYPE_* definitions?

Jan
Markus Armbruster - May 23, 2011, 1:14 p.m.
Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 2011-05-23 11:28, Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> Include the client type name into the output of 'info network'. The
>>> result looks like this:
>>>
>>> (qemu) info network
>>> VLAN 0 devices:
>>>   rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
>>> Devices not on any VLAN:
>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>    \ network1: type=tap,fd=5
>>>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>>
>>> Changes in v2:
>>>  - format type as "type=name"
>>>  - use standard type names
>>>  - factor out print_net_client
>>>
>>>  net.c |   25 ++++++++++++++++++++++---
>>>  1 files changed, 22 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/net.c b/net.c
>>> index 606ce70..6d06eb7 100644
>>> --- a/net.c
>>> +++ b/net.c
>>> @@ -1221,6 +1221,22 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
>>>      return 0;
>>>  }
>>>  
>>> +static void print_net_client(Monitor *mon, VLANClientState *vc)
>>> +{
>>> +    static const char *typename[] = {
>>> +        [NET_CLIENT_TYPE_NONE]   = "none",
>>> +        [NET_CLIENT_TYPE_NIC]    = "nic",
>>> +        [NET_CLIENT_TYPE_SLIRP]  = "user",
>>> +        [NET_CLIENT_TYPE_TAP]    = "tap",
>>> +        [NET_CLIENT_TYPE_SOCKET] = "socket",
>>> +        [NET_CLIENT_TYPE_VDE]    = "vde",
>>> +        [NET_CLIENT_TYPE_DUMP]   = "dump",
>>> +    };
>>> +
>>> +    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
>>> +                   typename[vc->info->type], vc->info_str);
>>> +}
>> 
>> Any particular reason for using typename[vc->info->type] instead of
>> net_client[types[vc->info->type].type?
>
> Uncertainty about the sorting of that array. Is it supposed to be
> aligned to NET_CLIENT_TYPE_* definitions?

Hmm, you're right: it happens to be in order, but it's not explicit, so
you can't rely on it.  I'd be tempted to make the order explicit, but
it's your call.
Jan Kiszka - May 23, 2011, 2:18 p.m.
On 2011-05-23 15:14, Markus Armbruster wrote:
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
>> On 2011-05-23 11:28, Markus Armbruster wrote:
>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>
>>>> Include the client type name into the output of 'info network'. The
>>>> result looks like this:
>>>>
>>>> (qemu) info network
>>>> VLAN 0 devices:
>>>>   rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
>>>> Devices not on any VLAN:
>>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>>    \ network1: type=tap,fd=5
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> ---
>>>>
>>>> Changes in v2:
>>>>  - format type as "type=name"
>>>>  - use standard type names
>>>>  - factor out print_net_client
>>>>
>>>>  net.c |   25 ++++++++++++++++++++++---
>>>>  1 files changed, 22 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/net.c b/net.c
>>>> index 606ce70..6d06eb7 100644
>>>> --- a/net.c
>>>> +++ b/net.c
>>>> @@ -1221,6 +1221,22 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
>>>>      return 0;
>>>>  }
>>>>  
>>>> +static void print_net_client(Monitor *mon, VLANClientState *vc)
>>>> +{
>>>> +    static const char *typename[] = {
>>>> +        [NET_CLIENT_TYPE_NONE]   = "none",
>>>> +        [NET_CLIENT_TYPE_NIC]    = "nic",
>>>> +        [NET_CLIENT_TYPE_SLIRP]  = "user",
>>>> +        [NET_CLIENT_TYPE_TAP]    = "tap",
>>>> +        [NET_CLIENT_TYPE_SOCKET] = "socket",
>>>> +        [NET_CLIENT_TYPE_VDE]    = "vde",
>>>> +        [NET_CLIENT_TYPE_DUMP]   = "dump",
>>>> +    };
>>>> +
>>>> +    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
>>>> +                   typename[vc->info->type], vc->info_str);
>>>> +}
>>>
>>> Any particular reason for using typename[vc->info->type] instead of
>>> net_client[types[vc->info->type].type?
>>
>> Uncertainty about the sorting of that array. Is it supposed to be
>> aligned to NET_CLIENT_TYPE_* definitions?
> 
> Hmm, you're right: it happens to be in order, but it's not explicit, so
> you can't rely on it.  I'd be tempted to make the order explicit, but
> it's your call.

Checked again: net_client is terminated by a NULL entry. If we put
certain entries on fixed slots, that would created premature list
termination if some features is missing (e.g. VDE is configured out). So
we actually need a separate name array.

Jan
Markus Armbruster - May 23, 2011, 3:11 p.m.
Jan Kiszka <jan.kiszka@siemens.com> writes:

> On 2011-05-23 15:14, Markus Armbruster wrote:
>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 
>>> On 2011-05-23 11:28, Markus Armbruster wrote:
>>>> Jan Kiszka <jan.kiszka@siemens.com> writes:
>>>>
>>>>> Include the client type name into the output of 'info network'. The
>>>>> result looks like this:
>>>>>
>>>>> (qemu) info network
>>>>> VLAN 0 devices:
>>>>>   rtl8139.0: type=nic,model=rtl8139,macaddr=52:54:00:12:34:57
>>>>> Devices not on any VLAN:
>>>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>>>    \ network1: type=tap,fd=5
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>>  - format type as "type=name"
>>>>>  - use standard type names
>>>>>  - factor out print_net_client
>>>>>
>>>>>  net.c |   25 ++++++++++++++++++++++---
>>>>>  1 files changed, 22 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/net.c b/net.c
>>>>> index 606ce70..6d06eb7 100644
>>>>> --- a/net.c
>>>>> +++ b/net.c
>>>>> @@ -1221,6 +1221,22 @@ int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
>>>>>      return 0;
>>>>>  }
>>>>>  
>>>>> +static void print_net_client(Monitor *mon, VLANClientState *vc)
>>>>> +{
>>>>> +    static const char *typename[] = {
>>>>> +        [NET_CLIENT_TYPE_NONE]   = "none",
>>>>> +        [NET_CLIENT_TYPE_NIC]    = "nic",
>>>>> +        [NET_CLIENT_TYPE_SLIRP]  = "user",
>>>>> +        [NET_CLIENT_TYPE_TAP]    = "tap",
>>>>> +        [NET_CLIENT_TYPE_SOCKET] = "socket",
>>>>> +        [NET_CLIENT_TYPE_VDE]    = "vde",
>>>>> +        [NET_CLIENT_TYPE_DUMP]   = "dump",
>>>>> +    };
>>>>> +
>>>>> +    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
>>>>> +                   typename[vc->info->type], vc->info_str);
>>>>> +}
>>>>
>>>> Any particular reason for using typename[vc->info->type] instead of
>>>> net_client[types[vc->info->type].type?
>>>
>>> Uncertainty about the sorting of that array. Is it supposed to be
>>> aligned to NET_CLIENT_TYPE_* definitions?
>> 
>> Hmm, you're right: it happens to be in order, but it's not explicit, so
>> you can't rely on it.  I'd be tempted to make the order explicit, but
>> it's your call.
>
> Checked again: net_client is terminated by a NULL entry. If we put
> certain entries on fixed slots, that would created premature list
> termination if some features is missing (e.g. VDE is configured out). So
> we actually need a separate name array.

Fixable; there's just one user.  But again: it's your call.
Jan Kiszka - May 23, 2011, 4:23 p.m.
On 2011-05-23 17:11, Markus Armbruster wrote:
>> Checked again: net_client is terminated by a NULL entry. If we put
>> certain entries on fixed slots, that would created premature list
>> termination if some features is missing (e.g. VDE is configured out). So
>> we actually need a separate name array.
> 
> Fixable; there's just one user.  But again: it's your call.

OK, I give up :). Will resend the whole thing with refactored
net_client_types to use them for output as well.

Jan

Patch

diff --git a/net.c b/net.c
index 606ce70..6d06eb7 100644
--- a/net.c
+++ b/net.c
@@ -1221,6 +1221,22 @@  int do_netdev_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
     return 0;
 }
 
+static void print_net_client(Monitor *mon, VLANClientState *vc)
+{
+    static const char *typename[] = {
+        [NET_CLIENT_TYPE_NONE]   = "none",
+        [NET_CLIENT_TYPE_NIC]    = "nic",
+        [NET_CLIENT_TYPE_SLIRP]  = "user",
+        [NET_CLIENT_TYPE_TAP]    = "tap",
+        [NET_CLIENT_TYPE_SOCKET] = "socket",
+        [NET_CLIENT_TYPE_VDE]    = "vde",
+        [NET_CLIENT_TYPE_DUMP]   = "dump",
+    };
+
+    monitor_printf(mon, "%s: type=%s,%s\n", vc->name,
+                   typename[vc->info->type], vc->info_str);
+}
+
 void do_info_network(Monitor *mon)
 {
     VLANState *vlan;
@@ -1231,7 +1247,8 @@  void do_info_network(Monitor *mon)
         monitor_printf(mon, "VLAN %d devices:\n", vlan->id);
 
         QTAILQ_FOREACH(vc, &vlan->clients, next) {
-            monitor_printf(mon, "  %s: %s\n", vc->name, vc->info_str);
+            monitor_printf(mon, "  ");
+            print_net_client(mon, vc);
         }
     }
     monitor_printf(mon, "Devices not on any VLAN:\n");
@@ -1239,10 +1256,12 @@  void do_info_network(Monitor *mon)
         peer = vc->peer;
         type = vc->info->type;
         if (!peer || type == NET_CLIENT_TYPE_NIC) {
-            monitor_printf(mon, "  %s: %s\n", vc->name, vc->info_str);
+            monitor_printf(mon, "  ");
+            print_net_client(mon, vc);
         }
         if (peer && type == NET_CLIENT_TYPE_NIC) {
-            monitor_printf(mon, "   \\ %s: %s\n", peer->name, peer->info_str);
+            monitor_printf(mon, "   \\ ");
+            print_net_client(mon, peer);
         }
     }
 }