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

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

 



On 2012-05-24 11:51, Zhi Yong Wu wrote:
> On Thu, May 24, 2012 at 10:43 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>> On 2012-05-24 11:38, Zhi Yong Wu wrote:
>>> On Thu, May 24, 2012 at 10:31 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>>>> On 2012-05-24 11:27, Zhi Yong Wu wrote:
>>>>> On Thu, May 24, 2012 at 10:25 PM, Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote:
>>>>>> Something mangled your reply and made it unreadable. Please retry.
>>>>> Sorry. let it look like below. Do you think of it? typ=hubport
>>>>>
>>>>> (qemu) info network
>>>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>>>    \ hub0port0: type=hubport,
>>>>>   virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>>>    \ hub1port0: type=hubport,
>>>>>   virtio-net-pci.2: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:58
>>>>>    \ u: type=user,net=10.0.2.0,restrict=off
>>>>>   e1000.0: type=nic,model=e1000,macaddr=52:54:00:12:34:59
>>>>>    \ ur: type=user,net=10.0.2.0,restrict=off
>>>>> hub 1
>>>>>     port 1 peer user.1
>>>>>     port 0 peer virtio-net-pci.1
>>>>> hub 0
>>>>>     port 1 peer user.0
>>>>>     port 0 peer virtio-net-pci.0
>>>>
>>>> My question remains: What added value we get from listing the hubs with
>>>> its ports separately from the port connections? Also, how would this be
>>>> printed:
>>>>
>>>>    -net user -net dump -net nic
>>> (qemu) info network
>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>    \ hub0port0: type=hubport,
>>>   virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>    \ hub1port0: type=hubport,
>>> hub 1
>>>     port 2 peer dump.0
>>>     port 1 peer user.1
>>>     port 0 peer virtio-net-pci.1
>>> hub 0
>>>     port 1 peer user.0
>>>     port 0 peer virtio-net-pci.0
>>> (qemu)
>>>
>>>>
>>>> The user should only be interested in the fact that user.0, dump.0 and
>>>> <some_nic>.0 are attached to the same hub, not to which port of that hub.
>>> OK, then let it seem like below. right?
>>>
>>> (qemu) info network
>>>   virtio-net-pci.0: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
>>>    \ hub0port0: type=hubport,
>>>   virtio-net-pci.1: type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:57
>>>    \ hub1port0: type=hubport,
>>> hub 1
>>>   \ dump.0
>>>   \ user.1
>>>   \ virtio-net-pci.1
>>> hub 0
>>>   \ user.0
>>>   \ virtio-net-pci.0
>>> (qemu)
>>
>> And, still, what is the added value of this verbose form compared to my
> They are same, i think.

Then let's got for the more compact form I proposed.

>> compact proposal? Please don't remark that it's easier to implement. ;)
> The implementation is not one difficult thing, if we reach agreement
> about its layout.
> For those NIC which aren't in one hub, they should been kept compact
> with old qemu form.

Yes. The form would be

peer
 \ peer

for the classic couples and

hub
 \ peer
 \ peer
 \ ...

for those that are attached to a hub.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux