Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
ie. printing the hubs first, listing all the peers of their ports
underneath them. Also, things like type=(null) should be avoided.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
Please see below.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
It is completely wrong. In one hub, one NIC emulated driver such as
virtio-net peers with one hub port; while its network backend such as
user peers with another hub port in the same hub. This is hub work
logic. Of course, you can add one dump network backend to this hub via
one hub port.
ie. printing the hubs first, listing all the peers of their ports
underneath them. Also, things like type=(null) should be avoided.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
For this output, we can't find which port peers with which emulated
NIC or network backend.
ie. printing the hubs first, listing all the peers of their ports
underneath them. Also, things like type=(null) should be avoided.
For this info, we can simply remove it.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
ie. printing the hubs first, listing all the peers of their ports
underneath them. Also, things like type=(null) should be avoided.
Let it look like as below, do you think of it?
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=hubport,
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=hubport,
virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
\ u: type=user,net=10.0.2.0,restrict=off
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 09:27, Zhi Yong Wu wrote:
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
Please see below.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
It is completely wrong.
(Note: my example is not a different representation of yours, it's a
different setup).
In one hub, one NIC emulated driver such as
virtio-net peers with one hub port; while its network backend such as
user peers with another hub port in the same hub. This is hub work
logic. Of course, you can add one dump network backend to this hub via
one hub port.
The output should reflect the logical connection in an easily
understandable way, not just the internal relations of netdev peers. If
the data structures do not allow direct dumping in the proper form, it
simply takes a bit more effort to do this.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 09:34, Zhi Yong Wu wrote:
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
For this output, we can't find which port peers with which emulated
NIC or network backend.
Why? This information should be available at least in the hubs. The info
network routine could call into a dumping helper of the hub to make it
available for visualization. It is surely not impossible, just not as
straightforward as it was so far.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-24 09:27, Zhi Yong Wu wrote:
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com
wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
Please see below.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
It is completely wrong.
(Note: my example is not a different representation of yours, it's a
different setup).
Sorry, i don't understand what the benefit for your layout is? And we
can not see which hub port peers with which NIC driver or network
backend.
In one hub, one NIC emulated driver such as
virtio-net peers with one hub port; while its network backend such as
user peers with another hub port in the same hub. This is hub work
logic. Of course, you can add one dump network backend to this hub via
one hub port.
The output should reflect the logical connection in an easily
Do you think that my output can not reflect this hub logical
connection? To be honest, i think it can than yours. :)
understandable way, not just the internal relations of netdev peers. If
the data structures do not allow direct dumping in the proper form, it
simply takes a bit more effort to do this.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
-22 07:35, Igor Mammedov wrote: Move from apic_init in pc.c the code that belongs … 9:46 pm Jason .. Yinghai (20)[PATCH] pci hotplug: rescan bridge after device hotplug - I'm tyring to support bridge hotplug and devices below it in qemu via acpi hotplug. Currently …9:44 pm Fabio .. Mark, Marc (28)mc13xxx-core: kernel hangs after 'regmap_read' - Hi Marc, I am running linux-next 3.4.0-next-20120521 on a mx31pdk board that has a mc13783 PMIC … 9:44 pm Michal Privoznik[libvirt] [PATCH] security: Switch to C99-style struct initialization - src/security/security_apparmor.c | 50 ++ src/security … 9:43 pm Peter .. Michal, Daniel (7)[libvirt] [PATCH 4/5] qemu: implement virConnectListAllDomains() for qemu driver - This patch adds a basic implementation of the listing code for virConnectListAllDomains() to qemu …9:41 pm loodyabout input/hid - hi all: I have some questions about input/hid devices. 1. it seems only usb hid has reports_desc … 9:39 pm Hui, Andi, Hui (5)[PATCH]KGTP (Linux Kernel debugger and tracer) lite patch for review - On Thu, May 10, 2012 at 08:15:36PM +0800, Hui Zhu wrote: On 05/09/12 22:05, Andi Kleen wrote … 9:37 pm majianpengthe max size of block device on 32bit os,when using do_generic_file_read() proceed. - Hi all: I readed a raid5,which size 30T.OS is RHEL6 32bit. I reaed the raid5(as a whole,not … 9:37 pm TeLeMan .. Jan, Andreas (18)[Qemu-devel] [PATCH] exec: fix breakpoint_invalidate() breakage - This breakage was introduced by the commit memory: make phys_page_find() return an …9:36 pm me, Jan (10)[Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info - On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05 … 9:33 pm Jesper, Hans, Christoph (3)[RFC PATCH] tcp: Fast/early SYN handling to mitigate SYN floods - Hi Eric, I have been doing some TCP performance measurements with SYN flooding, and have found … 9:32 pm Christian .. Alexander (4)[Qemu-devel] [PATCH 1/1] Fix geometry sector calculation - Currently the sector value for the geometry is masked, even if the user usesa command line … 9:27 pm Keith, Matthew (4)[PATCH] acpi/video: Don't restore backlight to 0 at boot time - If the initial ACPI reported backlight level is zero, or larger than max_level, then ignore it … 9:25 pm Tejun .. Vivek, Sasha (10)[PATCH 2/2] cgroup: make css-refcnt clearing on cgroup removal optional - Currently, cgroup removal tries to drain all css references. If there are active css references … 9:23 pm Mike, Peter, Peter (3)[rfc][patch] select_idle_sibling() inducing bouncing on westmere - I love the goodstuff select_idle_sibling() delivers, but do wish the two-faced little bi^Hugger … 9:21 pm salih duranoğluFw: devel Digest, Vol 57, Issue 175 - yollama e mailini yeter... Send devel mailing list submissions to de...@linuxdriverproject.org To … 9:19 pm Wen, Eric, Wen (3)[libvirt] [PATCH] fix building error on non fedora system - We forget to define with_storage_rbd if the system is not fedora, or the version is less than 16 …9:19 pm Conference CoordinatorInvitation to Global Fair 2012 - Invitation to Global Fair 2012 Dear Participants, I am please to invite you to the Africa Global … 9:15 pm klmckinney1, Dan (3)[PATCH 1/2] Staging: bcm: Add typedef back for bcm_ip_address, and convert struct back ... - From: Kevin McKinney klmckinn...@gmail.com This patch adds typedef back for … 9:11 pm Ashish Jangam[PATCH] Watchdog: DA9052/53 PMIC watchdog support v5 - This driver adds support for the watchdog functionality provided by the Dialog Semiconductor … 9:03 pm Alon, Gerd (2)[Qemu-devel] [PATCH 3/4] hmp/qxl: info spice: add qxl info - For all devices print id, mode and guest_bug status. Known problems: Prints devices from highest … 8:59 pm qemu, Luiz (2)[Qemu-devel] buildbot failure in qemu on block_openbsd_4.9 - The Buildbot has detected a new failure on builder block_openbsd_4.9 while building qemu. Full … 8:53 pm Oliver, Volkan (6)[ovs-discuss] Upgraded to openvswitch-1.4.1 and still high load and polluted syslog - Hi *, as suggested by Ben I upgraded to 1.4.1 and configured with following command: ovs … 8:51 pm Felipe Balbi[PATCH] usb: dwc3: add trace support - This patch add a few tracepoints to the DWC3 driver in order to aid debugging. NYET-Signed-off-by … 8:50 pm Xudong, David (3)[PATCH v2] intel-iommu: Add device info into list before doing context mapping - On Fri, 2012-03-23 at 02:54 +, Hao, Xudong wrote: Any other comments for this patch? Or …8:47 pm George, Dave, Francois (6)NETDEV WATCHDOG: %s (%s): transmit queue %u timed out - After installing a 3.4 kernel, I got the following: [ cut here ] WARNING …8:46 pm jamal[PATCH] MAINTAINERS - commit 2c2996304c01a7af350c431c0445ae7956c5ff30 Author: Jamal Hadi Salim j...@mojatatu.com … 8:45 pm Fengguang WuRe: Compile error: drivers/video/backlight/lcd.c:35:7: error: ‘FB_EARLY_EVENT_BLANK’ un... - On Wed, May 23, 2012 at 01:29:41PM -0700, Andrew Morton wrote: On Wed, 23 May 2012 19
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 11:12, Zhi Yong Wu wrote:
On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-24 09:27, Zhi Yong Wu wrote:
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 23:42, Zhi Yong Wu wrote:
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com
wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
That is true. But the output formatting is still improvable.
Please see below.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0:
type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1:
type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
What about a layout like this:
hub.0
\ virtio-net-pci.0: ...
\ virtio-net-pci.1: ...
\ user.0: ...
hub.1
\ e1000.0: ...
e1000.1: ...
\ user.1: ...
It is completely wrong.
(Note: my example is not a different representation of yours, it's a
different setup).
Sorry, i don't understand what the benefit for your layout is? And we
To see at one glance which peers are connected via a hub with eachother.
can not see which hub port peers with which NIC driver or network
backend.
What is the benefit of printing the port number? Is it part of the
user-visible interface? Does the port number make any difference for the
attached peer?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 11:14, Zhi Yong Wu wrote: For this output, we can't find which port peers with which emulated NIC or network backend. Why? This information should be available at least in the hubs. The info Sorry, More 18 of 121,110 Why this ad?Best VPN for China Users - mystrongvpn.org/~Instant_Approval - Unblock Now - Top Speeds - Secure 24x7 Live Technical and Sales Help512 Markus .. Anthony (11)[Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new - To create objects via QMP. Test case: $ upstream-qemu --enable-kvm -S -m 384 -vnc :0 -monitor … 10:12 pm [...] Something mangled your reply and made it unreadable. Please retry. Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 port 2 peer dump.0 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 (qemu) The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. OK, then let it seem like below. right? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 (qemu) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 11:38, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 port 2 peer dump.0 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 (qemu) The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. OK, then let it seem like below. right? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 (qemu) And, still, what is the added value of this verbose form compared to my compact proposal? Please don't remark that it's easier to implement. ;) Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:38, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 port 2 peer dump.0 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 (qemu) The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. OK, then let it seem like below. right? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 (qemu) And, still, what is the added value of this verbose form compared to my They are same, i think. compact proposal? Please don't remark that it's easier to implement. ;) The implementation is not one difficult thing, if we reach agreement about its layout. For those NIC which aren't in one hub, they should been kept compact with old qemu form. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:38, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 port 2 peer dump.0 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 (qemu) The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. OK, then let it seem like below. right? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 (qemu) And, still, what is the added value of this verbose form compared to my compact proposal? Please don't remark that it's easier to implement. ;) By the way, if you agree that below form is ok, i will send v3. Can you let me know your opinion? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:58 \ u: type=tap,ifname=tap0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-24 11:51, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:38, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka jan.kis...@siemens.com wrote: On 2012-05-24 11:27, Zhi Yong Wu wrote: On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka jan.kis...@siemens.com wrote: Something mangled your reply and made it unreadable. Please retry. Sorry. let it look like below. Do you think of it? typ=hubport (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58 \ u: type=user,net=10.0.2.0,restrict=off e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59 \ ur: type=user,net=10.0.2.0,restrict=off hub 1 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 My question remains: What added value we get from listing the hubs with its ports separately from the port connections? Also, how would this be printed: -net user -net dump -net nic (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 port 2 peer dump.0 port 1 peer user.1 port 0 peer virtio-net-pci.1 hub 0 port 1 peer user.0 port 0 peer virtio-net-pci.0 (qemu) The user should only be interested in the fact that user.0, dump.0 and some_nic.0 are attached to the same hub, not to which port of that hub. OK, then let it seem like below. right? (qemu) info network virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56 \ hub0port0: type=hubport, virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57 \ hub1port0: type=hubport, hub 1 \ dump.0 \ user.1 \ virtio-net-pci.1 hub 0 \ user.0 \ virtio-net-pci.0 (qemu) And, still, what is the added value of this verbose form compared to my They are same, i think. Then let's got for the more compact form I proposed. compact proposal? Please don't remark that it's easier to implement. ;) The implementation is not one difficult thing, if we reach agreement about its layout. For those NIC which aren't in one hub, they should been kept compact with old qemu form. Yes. The form would be peer \ peer for the classic couples and hub \ peer \ peer \ ... for those that are attached to a hub. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
[Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
--
1.7.6
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
-monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka jan.kis...@siemens.com wrote:
On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/net.c b/net.c
index 61dc28d..8c8e703 100644
--- a/net.c
+++ b/net.c
@@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
NetClientState *nc, *peer;
net_client_type type;
- monitor_printf(mon, Devices not on any VLAN:\n);
QTAILQ_FOREACH(nc, net_clients, next) {
peer = nc-peer;
type = nc-info-type;
This looks suspicious - or the patch description is improvable. This is
really just about removing that headline? And what about the indention
of the lines printed afterward?
As you have known, vlan concept is replaced with hub. So i think that
it is more reasonable to remove this in monitor.
It also leads me to the question how hub-based networks will be
visualized on info network, specifically when there are multiple hubs.
Can you provide some more complex example of an info network output?
(qemu) info network
virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
\ hub0port0: type=(null),
virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
\ hub1port0: type=(null),
hub 1
port 1 peer user.1
port 0 peer virtio-net-pci.1
hub 0
port 1 peer user.0
port 0 peer virtio-net-pci.0
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
