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

Submitted by Jan Kiszka on May 20, 2011, 4:19 p.m.

Details

Message ID 4DD694A9.2070209@siemens.com
State New
Headers show

Commit Message

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(-)

Comments

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 hide | download patch | download mbox

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);
         }
     }
 }