On Thu, May 24, 2012 at 9:30 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2012-05-24 09:27, Zhi Yong Wu wrote:
>> On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <jan.kis...@siemens.com> wrote:
>>> On 2012-05-23 23:42, Zhi Yong Wu wrote:
>>>> On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <jan.kis...@siemens.com>
>>>> wrote:
>>>>> On 2012-05-23 12:14, zwu.ker...@gmail.com wrote:
>>>>>> From: Zhi Yong Wu <wu...@linux.vnet.ibm.com>
>>>>>>
>>>>>> Signed-off-by: Zhi Yong Wu <wu...@linux.vnet.ibm.com>
>>>>>> ---
>>>>>> net.c | 1 -
>>>>>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>>>>>
>>>>>> diff --git a/net.c b/net.c
>>>>>> index 61dc28d..8c8e703 100644
>>>>>> --- a/net.c
>>>>>> +++ b/net.c
>>>>>> @@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
>>>>>> NetClientState *nc, *peer;
>>>>>> net_client_type type;
>>>>>>
>>>>>> - monitor_printf(mon, "Devices not on any VLAN:\n");
>>>>>> QTAILQ_FOREACH(nc, &net_clients, next) {
>>>>>> peer = nc->peer;
>>>>>> type = nc->info->type;
>>>>>
>>>>> This looks suspicious - or the patch description is improvable. This is
>>>>> really just about removing that headline? And what about the indention
>>>>> of the lines printed afterward?
>>>> As you have known, vlan concept is replaced with hub. So i think that
>>>> it is more reasonable to remove this in monitor.
>>>
>>> That is true. But the output formatting is still improvable.
>> Please see below.
>>>
>>>>>
>>>>> It also leads me to the question how hub-based networks will be
>>>>> visualized on "info network", specifically when there are multiple hubs.
>>>>> Can you provide some more complex example of an info network output?
>>>>
>>>> (qemu) info network
>>>> virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>> \ hub0port0: type=(null),
>>>> virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>> \ hub1port0: type=(null),
>>>> hub 1
>>>> port 1 peer user.1
>>>> port 0 peer virtio-net-pci.1
>>>> hub 0
>>>> port 1 peer user.0
>>>> port 0 peer virtio-net-pci.0
>>>
>>> What about a layout like this:
>>>
>>> hub.0
>>> \ virtio-net-pci.0: ...
>>> \ virtio-net-pci.1: ...
>>> \ user.0: ...
>>> hub.1
>>> \ e1000.0: ...
>>> e1000.1: ...
>>> \ user.1: ...
>> It is completely wrong.
>
> (Note: my example is not a different representation of yours, it's a
> different setup).
Sorry, i don't understand what the benefit for your layout is? And we
can not see which hub port peers with which NIC driver or network
backend.
>
>> In one hub, one NIC emulated driver such as
>> virtio-net peers with one hub port; while its network backend such as
>> user peers with another hub port in the same hub. This is hub work
>> logic. Of course, you can add one dump network backend to this hub via
>> one hub port.
>
> The output should reflect the logical connection in an easily
Do you think that my output can not reflect this hub logical
connection? To be honest, i think it can than yours. :)
> understandable way, not just the internal relations of netdev peers. If
> the data structures do not allow direct dumping in the proper form, it
> simply takes a bit more effort to do this.
>
> Jan
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
--
Regards,
Zhi Yong Wu
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
