| Message ID | 4DD694A9.2070209@siemens.com |
|---|---|
| State | New |
| Headers | show |
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? [...]
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
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.
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
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.
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
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); } } }
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(-)