qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v2 13/15] net: Remove obsolete vlan info
Date: Thu, 24 May 2012 10:30:55 -0300
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-05-24 09:27, Zhi Yong Wu wrote:
> On Thu, May 24, 2012 at 8:09 PM, Jan Kiszka <address@hidden> wrote:
>> On 2012-05-23 23:42, Zhi Yong Wu wrote:
>>> On Wed, May 23, 2012 at 11:41 PM, Jan Kiszka <address@hidden> wrote:
>>>> On 2012-05-23 12:14, address@hidden wrote:
>>>>> From: Zhi Yong Wu <address@hidden>
>>>>>
>>>>> Signed-off-by: Zhi Yong Wu <address@hidden>
>>>>> ---
>>>>>  net.c |    1 -
>>>>>  1 files changed, 0 insertions(+), 1 deletions(-)
>>>>>
>>>>> diff --git a/net.c b/net.c
>>>>> index 61dc28d..8c8e703 100644
>>>>> --- a/net.c
>>>>> +++ b/net.c
>>>>> @@ -1079,7 +1079,6 @@ void do_info_network(Monitor *mon)
>>>>>      NetClientState *nc, *peer;
>>>>>      net_client_type type;
>>>>>
>>>>> -    monitor_printf(mon, "Devices not on any VLAN:\n");
>>>>>      QTAILQ_FOREACH(nc, &net_clients, next) {
>>>>>          peer = nc->peer;
>>>>>          type = nc->info->type;
>>>>
>>>> This looks suspicious - or the patch description is improvable. This is
>>>> really just about removing that headline? And what about the indention
>>>> of the lines printed afterward?
>>> As you have known, vlan concept is replaced with hub. So i think that
>>> it is more reasonable to remove this in monitor.
>>
>> That is true. But the output formatting is still improvable.
> Please see below.
>>
>>>>
>>>> It also leads me to the question how hub-based networks will be
>>>> visualized on "info network", specifically when there are multiple hubs.
>>>> Can you provide some more complex example of an info network output?
>>>
>>> (qemu) info network
>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>    \ hub0port0: type=(null),
>>>   virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>    \ hub1port0: type=(null),
>>> hub 1
>>>     port 1 peer user.1
>>>     port 0 peer virtio-net-pci.1
>>> hub 0
>>>     port 1 peer user.0
>>>     port 0 peer virtio-net-pci.0
>>
>> What about a layout like this:
>>
>> hub.0
>>  \ virtio-net-pci.0: ...
>>  \ virtio-net-pci.1: ...
>>  \ user.0: ...
>> hub.1
>>  \ e1000.0: ...
>> e1000.1: ...
>>  \ user.1: ...
> It is completely wrong.

(Note: my example is not a different representation of yours, it's a
different setup).

> In one hub, one NIC emulated driver such as
> virtio-net peers with one hub port; while its network backend such as
> user peers with another hub port in the same hub. This is hub work
> logic. Of course, you can add one dump network backend to this hub via
> one hub port.

The output should reflect the logical connection in an easily
understandable way, not just the internal relations of netdev peers. If
the data structures do not allow direct dumping in the proper form, it
simply takes a bit more effort to do this.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

[Prev in Thread] Current Thread [Next in Thread]