| Message ID | 1337786045-2277-14-git-send-email-zwu.kernel@gmail.com |
|---|---|
| State | New |
| Headers | show |
On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: > From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> > > Signed-off-by: Zhi Yong Wu <wuzhy@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
On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >> >> Signed-off-by: Zhi Yong Wu <wuzhy@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
On 2012-05-23 23:42, Zhi Yong Wu wrote: > On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>> >>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>> >>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>> >>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>> >>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On 2012-05-24 09:27, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>>> >>>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On 2012-05-24 09:34, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>>> >>>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka <jan.kiszka@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.kiszka@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.kiszka@siemens.com> wrote: >>>>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>>>> >>>>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
On Thu, May 24, 2012 at 9:33 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: > On 2012-05-24 09:34, Zhi Yong Wu wrote: >> On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>>>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>>>> >>>>>> Signed-off-by: Zhi Yong Wu <wuzhy@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 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 Jan, Jan, Max (9)[Qemu-devel] [PATCH] TCG: Fix TB invalidation after breakpoint insertion/deletion - From: Jan Kiszka <jan.kiszka@siemens.com> tb_invalidate_phys_addr has to called with the …10:11 pm Markus .. Peter, Anthony (6)[Qemu-devel] [PATCH RFC 0/2] QMP command qom-new - Beware: second patch is the product of voodoo-coding. Markus Armbruster (2): qom: Give … 10:11 pm Alex .. Peter, Arjan (25)[PATCH v7 8/8] x86/tlb: just do tlb flush on one of siblings of SMT - According to Intel's SDM, flush tlb on both of siblings of SMT is just wasting time, no any … 10:08 pm Stephen, Ingo, Peter (8)linux-next: build failure after merge of the final tree - Hi all, After merging the final tree, today's linux-next build (i386 defconfig) failed like …10:07 pm Idan, Boaz (4)exofs/ore: allocation of _ore_get_io_state() - _ore_get_io_state is supposed to allocate a struct ore_io_state, which is variable length … 10:06 pm Devendra Naga[PATCH] [emu10k1]: remove the kcallloc cast (reported from make coccicheck's drop_kmall... - Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> --- sound/pci/emu10k1/emufx.c | 2 … 10:04 pm David, Rusty (5)[PATCH 00/23] Crypto keys and module signing - Okay Rusty, Here's a set of patches that does module signing attaching the signature in the … 10:03 pm Paolo, Ori (2)[Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication] - On 24/05/2012 16:41, Paolo Bonzini wrote: > The dirty bitmap is managed by these QMP commands … 10:01 pm Joe, Jan (2)net/wanrouter? - Does anyone still use this? -- To unsubscribe from this list: send the line "unsubscribe … 9:53 pm Daniel P. Berrange[libvirt] [PATCH 1/2] Remove uid param from directory lookup APIs - From: "Daniel P. Berrange" <berrange@redhat.com> Remove the uid param from … 9:49 pm Daniel P. Berrange[libvirt] [PATCH 2/2] Add impl of APIs to get user directories on Win32 - From: "Daniel P. Berrange" <berrange@redhat.com> Add an impl of … 9:49 pm Daniel P. Berrange[libvirt] [PATCH 0/2] Fix virGetUserXXXDirectory on Win32 - The newly added APIs for getting user directories were causing a win32 build failure, due to … 9:48 pm Pavel .. Pavel .. Paolo (12)[Qemu-devel] [PATCH] Prevent disk data loss when closing qemu - From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo Bonzini > Il 23/05 … 9:47 pm Igor .. Jan, Andreas (18)[Qemu-devel] [PATCH qom-next 3/5] pc: move apic_mapped initialization into common apic ... - On 2012-05-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.kiszka@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 devel@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 <klmckinney1@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 +0000, 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 <jhs@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:13:29 … 8:42 pm Kevin Wolf (2)[Qemu-devel] [PATCH] qcow2: Check qcow2_alloc_clusters_at() return value - When using qcow2_alloc_clusters_at(), the cluster allocation code checked the wrong variable for … 8:41 pm Jiri, Peter, Stephane (5)[PATCH 01/16] perf: Unified API to record selective sets of arch registers - This brings a new API to help the selective dump of registers on event sampling, and its … 8:38 pm Jan, Jan, Dave (9)Hole punching and mmap races - On Wed 16-05-12 12:14:23, Dave Chinner wrote: > On Wed, May 16, 2012 at 12:48:05AM +0200, Jan … 8:35 pm Yu, Yu, Felipe (8)[PATCH v4] usb: gadget: mv: Add USB 3.0 device driver for Marvell PXA2128 chip. - It supports Marvell USB 3.0 device controller for PXA2128 chip. Signed-off-by: Yu Xu <yuxu … 8:33 pm Daniele MilaniRe: [ovs-dev] [ovs-discuss] Problem with DHCP and TUNNEL [SOLVED] - CC: jesse@nicira.com; dev@openvswitch.org; roberto.sassu@polito.it; paolo.smiraglia@polito.it … 8:32 pm Comrade, Andreas (2)PROBLEM: Performance drop - PROBLEM: Performance drop After the release of linux 3.4.0 I've updated the kernel on all my … 8:32 pm Daniel P. Berrange[libvirt] [PATCH] Add stub impl of virNetlinkEventServiceLocalPid for Win32 - From: "Daniel P. Berrange" <berrange@redhat.com> Pushed the following under build … 8:31 pm Richard, Alexander .. (7)[PATCH v2 4/4] USB: Chipidea: add ci13xxx device id management - Richard Zhao <richard.zhao@freescale.com> writes: > We simply use bitmap to manage the … 8:31 pm ><Why this ad?Best VPN for China Users - mystrongvpn.org/~Instant_Approval - Unblock Now - Top Speeds - Secure 24x7 Live Technical and Sales Help512 ><Why this ad?Dedicated Server $139 - www.micrahosting.com - Good speed in China and Taiwan 5TB Peer1 bandwidth, limited time.512 KVM mailing listkvm@vger.kernel.orgChat with KVMVideo chat with KVMmeInbox [Qemu-devel] [PATCH v2 12/15] net: Rename qemu_del_vlan_client() to qemu_del_net_client() - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Another step in moving the vlan feature … May 23 Liu .. Andrew, Michael (5)Inbox [Qemu-devel] [RFC:kvm] export host NUMA info to guest & make emulated device NUMA attr - On 05/22/2012 04:28 AM, Liu ping fan wrote: > On Sat, May 19, 2012 at 12:14 AM, Shirley Ma … May 23 meInbox [PATCH v2 04/15] hub: Check that hubs are configured correctly - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Checks can be performed to make sure … May 23 meInbox [Qemu-devel] [PATCH v2 02/15] net: Use hubs for the vlan feature - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Stop using the special-case vlan code … May 23 meInbox [Qemu-devel] [PATCH v2 01/15] net: Add a hub net client - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> The vlan feature can be implemented in … May 23 meInbox [Qemu-devel] [PATCH v2 00/15] net: hub-based networking - From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> The patchset implements network hub stead of … May 23 meInbox [PATCH v2 14/15] net: cleanup deliver/deliver_iov func pointers - From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by: Zhi Yong Wu <wuzhy@linux … May 23 meInbox [Qemu-devel] [PATCH v2 11/15] net: Rename vc local variables to nc - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Now that VLANClientState has been … May 23 meInbox [PATCH v2 07/15] net: Remove vlan code from net.c - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> The vlan implementation in net.c has … May 23 meInbox [PATCH v2 09/15] net: Rename non_vlan_clients to net_clients - From: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> There is no longer a distinction … May 23 Asias, Tejun (5)Inbox [RFC PATCH 1/5] block: Introduce q->abort_queue_fn() - On 05/22/2012 11:14 PM, Tejun Heo wrote: > Hello, > > On Tue, May 22, 2012 at 03:30:37PM … May 23 Gleb, Avi (3)Inbox [PATCH 2/2] Provide fast path for "rep ins" emulation if possible. - rep ins" emulation is going through emulator now. This is slow because emulator knows how to … May 23 Gleb NatapovInbox [PATCH 1/2] Provide userspace IO exit completion callback. - Current code assumes that IO exit was due to instruction emulation and handles execution back to … May 23 Gleb NatapovInbox [PATCH 0/2] improve speed of "rep ins" emulation - With this patches loading 100M initrd takes ~10s instead of ~40s without. Gleb Natapov (2 … May 23 Xudong Hao (2)Inbox [PATCH v3 4/4] Enabling Access bit when doing memory swapping - … redhat.com > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org; mtosatti@redhat.com … May 23 Zang, Avi (2)Inbox Is kvm-guest-drivers-linux.git still live? Is virtio-serial included? - Hi, To support linux guests with old kernel version, vitio driver backport is needed. But I … May 23 Xiao GuangrongInbox [PATCH v5 9/9] KVM: MMU: document mmu-lock and fast page fault - Document fast page fault and mmu-lock in locking.txt Signed-off-by: Xiao Guangrong … May 23 Xiao GuangrongInbox [PATCH v5 8/9] KVM: MMU: fix kvm_mmu_pagetable_walk tracepoint - The P bit of page fault error code is missed in this tracepoint, fix it by passing the full error … May 23 Avi KivityInbox [ANNOUNCE] qemu-kvm-1.1-rc3 - qemu-kvm-1.1-rc3 is now available. This release is based on the upstream qemu 1.1-rc3, plus kvm … May 23 Xiao GuangrongInbox [PATCH v5 2/9] KVM: MMU: abstract spte write-protect - Introduce a common function to abstract spte write-protect to cleanup the code Signed-off-by … May 23 ><Why this ad?Precision Foil Resistors - www.charcroft.com - Radials from 0.005% in 7-15 days SMDs from 0.01% in 15 days512 ><Why this ad?Fast VPN for China Users - www.mystrongvpn.org/~BestVPN - Instant Order Approval- Unblock Now 24x7 Live Technical and Sales Help512 Konrad, Stefano (2)[PATCH 3/4] xen/hvc: Check HVM_PARAM_CONSOLE_[EVTCHN|PFN] for correctness. - We need to make sure that those parameters are setup to be correct. As such the value of 0 is … 6:52 pm Guido, Eric (3)[libvirt] [PATCHv3 2/4] Introduce filesystem limits to virDomainFSDef - docs/formatdomain.html.in | 14 ++++++++++++++ docs/schemas/domaincommon.rng | 12 ++++++++++++ src …6:51 pm Pablo, Krishna (3)Re: [v4 PATCH 1/1] netfilter: Add fail-open support - My main objection with this patch is that it adds more code out of the scope of the nf_queue … 6:51 pm Konrad, Stefano (2)[PATCH 2/4] xen/hvc: Fix error cases around HVM_PARAM_CONSOLE_PFN - We weren't resetting the parameter to be passed in to a known default. Nor were we checking … 6:48 pm Chen .. Borislav (13)[PATCH] x86: auto poll/interrupt mode switch for CMC to stop CMC storm - This idea is inspired from IA64 implementation. It is like NAPI for network stack. When CMCI is … 6:48 pm Charle. .. Charle. .. (13)[Qemu-devel] The image size of instance VM keeps growing - Stefan, We can run a tool to see if there is any active I/O or not. Does the image size shrink … 6:41 pm Stephen, Mark (2)[PATCH] regmap: clean up debugfs if regmap_init fails - From: Stephen Warren <swarren@nvidia.com> If debugfs isn't cleaned up, stale files will … 6:39 pm tip-bot for Arnaldo Carv.[tip:perf/urgent] perf evlist: Explicititely initialize input_name - Commit-ID: a1d44b9acdf7b2820ef762846150b4d13b84e075 Gitweb: http://git.kernel.org/tip … 6:38 pm Felipe Balbi[PATCH 14/15] usb: dwc3: gadget: disable U1/U2 on disconnect - If we get a disconnect IRQ, we should take the core out of low power mode so we can reconnect … 6:38 pm Felipe Balbi[PATCH 15/15] usb: dwc3: gadget: move AcceptU1Ena and AcceptU2Ena to Reset IRQ - From: Gerard CAUVY <g-cauvy1@ti.com> According to the databook, the DWC3 Core will reset … 6:38 pm Felipe Balbi[PATCH 13/15] usb: dwc3: gadget: prevent DCTL register corruption - If we don't read out the contents of the register (in order to reinitialize 'reg … 6:37 pm Felipe Balbi[PATCH 12/15] usb: dwc3: core: make sure evt->lpos is correctly initialized - From: Paul Zimmerman <Paul.Zimmerman@synopsys.com> The same event buffers will be reused … 6:37 pm Felipe Balbi[PATCH 11/15] usb: dwc3: support new revisions of DWC3 core - From: Paul Zimmerman <Paul.Zimmerman@synopsys.com> Recent cores (>= 1.94a) have a set of … 6:37 pm Felipe Balbi[PATCH 10/15] usb: dwc3: gadget: rename phy_power() to phy_suspend() - From: Paul Zimmerman <Paul.Zimmerman@synopsys.com> those two functions don't power PHYs … 6:37 pm Felipe Balbi[PATCH 09/15] usb: dwc3: gadget: reinitialize retries - From: Paul Zimmerman <Paul.Zimmerman@synopsys.com> retries is used twice without being … 6:37 pm Felipe Balbi[PATCH 08/15] usb: dwc3: add definitions for new registers - From: Paul Zimmerman <Paul.Zimmerman@synopsys.com> This patch adds definitions for some new … 6:37 pm Felipe Balbi[PATCH 07/15] usb: dwc3: drop HAVE_CLK dependency from Exynos glue layer - commit ebbf0cb (clk: add non CONFIG_HAVE_CLK routines) added clk API stubs when !defined … 6:37 pm Felipe Balbi[PATCH 06/15] usb: dwc3: gadget: remove trailing semicolon - That semicolon doesn't do anything, it's not needed and should be removed. Signed-off-by … 6:37 pm Felipe Balbi[PATCH 05/15] usb: dwc3: ep0: fix a typo in comment - s/has/have. No functional changes, just a typo fix on a code comment. Signed-off-by: Felipe Balbi … 6:37 pm Felipe Balbi[PATCH 04/15] usb: dwc3: ep0: align on function signature - On our Transfer Not Ready handlers, only dwc3_ep0_do_control_status() had a different list of … 6:37 pm Felipe Balbi[PATCH 03/15] usb: dwc3: ep0: switch over to IS_ALIGNED - IS_ALIGNED provides a much faster operation for checking proper size alignment then a modulo … 6:37 pm Felipe Balbi[PATCH 02/15] usb: dwc3: handle pending unaligned Control OUT data phase correctly - When DWC3_EP_PENDING_REQUEST flag is set for a Control OUT Data phase transfer, we would be … 6:37 pm Felipe Balbi[PATCH 01/15] usb: dwc3: fix a WARN and a comment - we're now have DWC3_EP0_BOUNCE_SIZE to tell us the actual size of the bufer. Let's use … 6:37 pm Felipe Balbi[PATCH 00/15] pending dwc3 patches - Hi guys, here are a few patches I have been holding on a local branch. Once -rc1 is tagged, I … 6:37 pm Martin .. Konstantin (7)3.4-rc7: BUG: Bad rss-counter state mm:ffff88040b56f800 idx:1 val:-59 - Hi Andrew, while shutting down my laptop (Dell Vostro 3550 with 16GB RAM, core i7) with 3.4-rc7 I … 6:36 pm Ashish Jangam[PATCH] Watchdog: DA9052/53 PMIC watchdog support v4 - This driver adds support for the watchdog functionality provided by the Dialog Semiconductor … 6:35 pm Konrad, Stefano (2)[PATCH 1/4] xen/hvc: Collapse error logic. - All of the error paths are doing the same logic. In which case we might as well collapse them in … 6:34 pm Harsh Prateek Bora[Qemu-devel] [PATCH v2 3/3] Update simpletrace.py to support new v2 log format - With this patch, simpletrace.py can parse the older as well as the newer log format which … 6:33 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 Jinsong .. Borislav (4)[PATCH 1/3] xen/mce: Add mcelog support for Xen platform (v2) - From 4df7496eea9e92a3e267ffb0a4b8f5e6e0c29c36 Mon Sep 17 00:00:00 2001 From: Liu, Jinsong …6:30 pm Arnaldo, Ingo (2)[GIT PULL 0/1] perf/core fix - Hi Ingo, Please pull, - Arnaldo The following changes since commit … 6:30 pm Magnus, Paul, Thomas (5)[PATCH 01/03] clockevents: Make clockevents_config() a global symbol - From: Magnus Damm <damm@opensource.se> Make clockevents_config() into a global symbol to … 6:29 pm vamsi, Pavel (2)[PATCH 1/2] Staging:winbond: Fix coding style issues in wb35tx.c This is a patch in wb3... - drivers/staging/winbond/wb35tx.c | 63 +++++++++++++++++++ 1 file changed, 31 … 6:28 pm Sameer, Greg, Pavel (4)[PATCH] power: add knob for printing device resume times - Added a new knob called /sys/powe/pm_print_times. Setting it to 1 enables printing of time taken … 6:28 pm Sarah, Alan, Aman (3)Re: USB2.0 [EHCI] Issue : EHCI interrupt endpoints transfer is taking above 600 microse... - On Tue, May 22, 2012 at 09:45:46AM +0530, Aman Bansal wrote: > Dear Alan and Sarah … 6:22 pm Lin, Lin, Alan (14)[RFC v2 PATCH 2/4] block: add queue runtime pm callbacks - On Fri, May 18, 2012 at 2:29 AM, Alan Stern <stern@rowland.harvard.edu> wrote: [snip … 6:19 pm Ashish, Wim (3)[PATCH] Watchdog: Fix for settimeout issue - Some devices have a fixed minimum elapse time and a ping before this elapse time causes error … 6:19 pm Stanislav Kinsbursky[PATCH v2] NFSd: set nfsd_serv to NULL after service destruction - v2: 1) Set global nfsd_serv pointer to NULL only if no running threads left. Otherwise we will … 6:16 pm Harsh Prateek Bora[Qemu-devel] [PATCH v2 2/3] Simpletrace v2: Add support for multiple args, strings. - A newer tracelog format which gets rid of fixed size trace records and therefore allows to trace … 6:12 pm Harsh Prateek Bora[Qemu-devel] [PATCH v2 0/3] Simpletrace v2: Support multiple args, strings. - Existing simpletrace backend allows to trace at max 6 args and does not support strings. This … 6:11 pm Pavel .. Pavel .. Paolo (12)[Qemu-devel] [PATCH] Prevent disk data loss when closing qemu - From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo Bonzini > Il 23/05 … 9:47 pm Tomoya, Mark (18)[PATCH v3] sound/soc/lapis: add platform driver for ML7213 - This driver is for LAPIS Semiconductor ML7213 IOH I2S. Signed-off-by: Tomoya MORINAGA <tomoya … 6:08 pm Nieścierowi., Jamal (3)tc filter u32 match - Hello, I'm in the process of building a new shaper, when adding support for 802.1q vlan … 6:04 pm Richard .. Shmulik (18)[PATCH] [RFC] UBI: Implement Fastmap support - Fastmap (aka checkpointing) allows attaching of an UBI volume in nearly constant time. Only a … 6:04 pm Gao, Pablo (4)[PATCH 02/17] netfilter: add namespace support for l4proto - On Thu, May 24, 2012 at 09:52:51AM +0800, Gao feng wrote: > 于 2012年05月23日 18:25, Pablo … 6:00 pm u-boot-requestU-Boot Digest, Vol 48, Issue 33 - Send U-Boot mailing list submissions to u-boot@lists.denx.de To subscribe or unsubscribe via the … 6:00 pm Gao, Pablo (4)[PATCH 15/17] netfilter: cleanup sysctl for l4proto and l3proto - delete no useless sysctl data for l4proto and l3proto. Acked-by: Eric W. Biederman <ebiederm … 5:56 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 Alon Levy[Qemu-devel] [PATCH 4/4] qxl: stop dirty loging when not in vga mode - Tested with linux guest. Not sure how to check actual performance affect of this. Checked with … 5:54 pm Yongjie, Avi, Yongjie (5)which branch of kvm.git should I do regular testing against? - On 05/24/2012 12:33 PM, Ren, Yongjie wrote: >> >> On 05/24/2012 12:24 PM, Ren … 5:48 pm ><Why this ad?SyncLink SDLC/HDLC Cards - www.microgate.com - Synchronous SDLC/HDLC serial adapters for Windows and Linux512 >< Why this ad? Fast VPN for China Users - www.mystrongvpn.org/~BestVPN - Instant Order Approval- Unblock Now 24x7 Live Technical and Sales Help 512 [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info Inboxx ReplyReply to allForwardReply by chatFilter messages like thisPrintAdd to Contacts listDelete this messageReport phishingReport not phishingShow originalMessage text garbled?Why is this spam/nonspam?Translate messageMark unread from here zwu.kernel@gmail.comFrom: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by: Zhi Yong Wu <wuzh... 11:14 PM (22 hours ago) From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by: Zhi Yong Wu <wuzh... Jan KiszkaThis looks suspicious - or the patch description is improvable. This is reall... 11:41 PM (22 hours ago) This looks suspicious - or the patch description is improvable. This is reall... Zhi Yong WuAs you have known, vlan concept is replaced with hub. So i think that it is m... 10:42 AM (11 hours ago) As you have known, vlan concept is replaced with hub. So i think that it is m... 5 older messages Jan KiszkaThat is true. But the output formatting is still improvable. What about a lay... 8:09 PM (1 hour ago) That is true. But the output formatting is still improvable. What about a lay... Jan Kiszka8:09 PM (1 hour ago) Loading... Jan Kiszka 8:09 PM (2 hours ago) to me, qemu-devel, pbonzini, wuzhy, linuxram, stefanha, kvm On 2012-05-23 23:42, Zhi Yong Wu wrote: > On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <jan.kiszka@siemens.com> wrote: >> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>> >>> Signed-off-by: Zhi Yong Wu <wuzhy@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 Reply Reply to all Forward Zhi Yong WuPlease see below. It is completely wrong. In one hub, one NIC emulated driver... 8:27 PM (1 hour ago) Please see below. It is completely wrong. In one hub, one NIC emulated driver... Zhi Yong WuFor this output, we can't find which port peers with which emulated NIC or ne... 8:34 PM (1 hour ago) For this output, we can't find which port peers with which emulated NIC or ne... Zhi Yong WuLet it look like as below, do you think of it? \ hub0port0: type=hubport, \ h... 8:54 PM (1 hour ago) Let it look like as below, do you think of it? \ hub0port0: type=hubport, \ h... Zhi Yong Wu8:54 PM (1 hour ago) Loading... Zhi Yong Wu 8:54 PM (1 hour ago) to Jan, qemu-devel, pbonzini, wuzhy, linuxram, stefanha, kvm On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kiszka@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.kiszka@siemens.com> wrote: >>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>> >>>> Signed-off-by: Zhi Yong Wu <wuzhy@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? type=hubport 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 > 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
On 2012-05-24 11:12, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka <jan.kiszka@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.kiszka@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.kiszka@siemens.com> wrote: >>>>>> On 2012-05-23 12:14, zwu.kernel@gmail.com wrote: >>>>>>> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com> >>>>>>> >>>>>>> Signed-off-by: Zhi Yong Wu <wuzhy@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
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
On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka <jan.kiszka@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
On 2012-05-24 11:27, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka <jan.kiszka@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
On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka <jan.kiszka@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.kiszka@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
On 2012-05-24 11:38, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka <jan.kiszka@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.kiszka@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
On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka <jan.kiszka@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.kiszka@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.kiszka@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
On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka <jan.kiszka@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.kiszka@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.kiszka@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
On 2012-05-24 11:51, Zhi Yong Wu wrote: > On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka <jan.kiszka@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.kiszka@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.kiszka@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
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;