From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOVxd-0002Ai-Uz for qemu-devel@nongnu.org; Mon, 23 May 2011 10:18:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOVxc-0004oJ-SI for qemu-devel@nongnu.org; Mon, 23 May 2011 10:18:21 -0400 Received: from goliath.siemens.de ([192.35.17.28]:22108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOVxc-0004o8-IP for qemu-devel@nongnu.org; Mon, 23 May 2011 10:18:20 -0400 Message-ID: <4DDA6CA9.4000704@siemens.com> Date: Mon, 23 May 2011 16:18:17 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD2AAE5.1020408@siemens.com> <4DD6909A.5040906@siemens.com> <4DD692D5.4000706@siemens.com> <4DD694A9.2070209@siemens.com> <4DDA29B6.2010204@siemens.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 2/2] net: Dump client type 'info network' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel On 2011-05-23 15:14, Markus Armbruster wrote: > Jan Kiszka writes: > >> On 2011-05-23 11:28, Markus Armbruster wrote: >>> Jan Kiszka 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 >>>> --- >>>> >>>> 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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux