qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property


From: Zhi Yong Wu
Subject: Re: [Qemu-devel] [PATCH v4 06/16] net: Remove vlan qdev property
Date: Sat, 9 Jun 2012 11:04:26 +0800

On Sat, Jun 9, 2012 at 12:09 AM, Stefan Hajnoczi <address@hidden> wrote:
> On Fri, Jun 8, 2012 at 3:48 PM, Zhi Yong Wu <address@hidden> wrote:
>> On Fri, Jun 8, 2012 at 9:23 PM, Stefan Hajnoczi <address@hidden> wrote:
>>> On Mon, Jun 4, 2012 at 6:29 AM,  <address@hidden> wrote:
>>>> From: Stefan Hajnoczi <address@hidden>
>>>>
>>>> The vlan feature is implemented using hubs and no longer uses
>>>> special-purpose VLANState structs that are accessible as qdev
>>>> properties.
>>>>
>>>> Signed-off-by: Stefan Hajnoczi <address@hidden>
>>>> Signed-off-by: Zhi Yong Wu <address@hidden>
>>>> ---
>>>>  hw/qdev-properties.c |   72 
>>>> --------------------------------------------------
>>>>  hw/qdev.c            |    2 -
>>>>  hw/qdev.h            |    4 ---
>>>>  net.h                |    3 --
>>>>  4 files changed, 0 insertions(+), 81 deletions(-)
>>>
>>> This commit looks suspicious because it removes a user-visible qdev
>>> property but we're trying to preserve backward compatibility.  This
>>> command-line will break:
>>>
>>> x86_64-softmmu/qemu-system-x86_64 -net user,vlan=1 -device 
>>> virtio-net-pci,vlan=1
>> Should this type of syntax be supported? i know this at the first time
>>>
>>> Instead of dropping the qdev_prop_vlan completely the
>>> hw/qdev-properties.c code needs to call net/hub.h external functions
>>> to implement equivalent functionality:
>>>
>>> 1. Setting the vlan=<id> property looks up the hub port and assigns
>>> the NICConf->peer field.
>>> 2. Getting the vlan property looks up the hub id (i.e. vlan id) given
>>> the peer.  If the peer is not a hub port the result is -1.
>>>
>>> When I wrote this patch I missed the big picture and forgot about
>>> backwards compatibility :(.
>>>
>>> Do you feel comfortable rewriting this commit?
>> Do you mean that you would like to rewrite this by yourself?
>
> No, I meant do you agree with the changes that I suggested?  I wanted
> to make sure that you understand the problem that I'm describing and
> how it could be solved.
To be honest, i am concerned if anyone uses this syntax. Since the
feature will finally be discarded, i suggest that we don't support
this now. If someone complains this later, we can fix it. If nobody
complains, that is what we hope.
>
> Stefan



-- 
Regards,

Zhi Yong Wu



reply via email to

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