Patchwork [v2,13/15] net: Remove obsolete vlan info

login
register
mail settings
Submitter Zhiyong Wu
Date May 23, 2012, 3:14 p.m.
Message ID <1337786045-2277-14-git-send-email-zwu.kernel@gmail.com>
Download mbox | patch
Permalink /patch/160937/
State New
Headers show

Comments

Zhiyong Wu - May 23, 2012, 3:14 p.m.
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(-)
Jan Kiszka - May 23, 2012, 3:41 p.m.
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
Zhiyong Wu - May 24, 2012, 2:42 a.m.
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
Jan Kiszka - May 24, 2012, 12:09 p.m.
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
Zhiyong Wu - May 24, 2012, 12:27 p.m.
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
Zhiyong Wu - May 24, 2012, 12:34 p.m.
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
Zhiyong Wu - May 24, 2012, 12:54 p.m.
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
Jan Kiszka - May 24, 2012, 1:30 p.m.
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
Jan Kiszka - May 24, 2012, 1:33 p.m.
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
Zhiyong Wu - May 24, 2012, 2:12 p.m.
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
Zhiyong Wu - May 24, 2012, 2:14 p.m.
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-deve​l] [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
Jan Kiszka - May 24, 2012, 2:24 p.m.
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
Jan Kiszka - May 24, 2012, 2:25 p.m.
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
Zhiyong Wu - May 24, 2012, 2:27 p.m.
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
Jan Kiszka - May 24, 2012, 2:31 p.m.
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
Zhiyong Wu - May 24, 2012, 2:38 p.m.
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
Jan Kiszka - May 24, 2012, 2:43 p.m.
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
Zhiyong Wu - May 24, 2012, 2:51 p.m.
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
Zhiyong Wu - May 24, 2012, 2:59 p.m.
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
Jan Kiszka - May 24, 2012, 3:01 p.m.
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

Patch

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;