On Sat, Jun 9, 2012 at 12:09 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
> On Fri, Jun 8, 2012 at 3:48 PM, Zhi Yong Wu <zwu.ker...@gmail.com> wrote:
>> On Fri, Jun 8, 2012 at 9:23 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote:
>>> On Mon, Jun 4, 2012 at 6:29 AM,  <zwu.ker...@gmail.com> wrote:
>>>> From: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com>
>>>>
>>>> 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 <stefa...@linux.vnet.ibm.com>
>>>> Signed-off-by: Zhi Yong Wu <wu...@linux.vnet.ibm.com>
>>>> ---
>>>>  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