From: Eric Blake <eblake@redhat.com>
To: Amos Kong <akong@redhat.com>, qemu-devel@nongnu.org
Cc: vyasevic@redhat.com, lcapitulino@redhat.com, sf@sfritsch.de,
mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH] virtio-net: only output the vlan table when VIRTIO_NET_F_CTRL_VLAN is negotiated
Date: Mon, 17 Feb 2014 09:56:24 -0700 [thread overview]
Message-ID: <53023F38.5060406@redhat.com> (raw)
In-Reply-To: <53023E43.1000706@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]
On 02/17/2014 09:52 AM, Eric Blake wrote:
> On 02/16/2014 07:27 PM, Amos Kong wrote:
>> Stefan Fritsch just fixed a virtio-net driver bug [1], virtio-net won't
>> filter out VLAN-tagged packets if VIRTIO_NET_F_CTRL_VLAN isn't negotiated.
>>
>> We should also not send the vlan table to management, this patch makes
>> the vlan-talbe optional.
>
> s/talbe/table/
>
>> @@ -4053,7 +4053,7 @@
>> 'multicast-overflow': 'bool',
>> 'unicast-overflow': 'bool',
>> 'main-mac': 'str',
>> - 'vlan-table': ['int'],
>> + '*vlan-table': ['int'],
>
> Indentation is now off.
>
>> - "main-mac": main macaddr string (json-string)
>> -- "vlan-table": a json-array of active vlan id
>> +- "vlan-table": a json-array of active vlan id (optoinal)
>
> s/optoinal/optional/
>
> Those fixes are trivial enough, so I'm okay if you correct them then add:
Scratch that. I revoke my R-b, on the following grounds:
On 02/17/2014 08:27 AM, Vlad Yasevich wrote:
> On 02/16/2014 09:27 PM, Amos Kong wrote:
>> Stefan Fritsch just fixed a virtio-net driver bug [1], virtio-net won't
>> filter out VLAN-tagged packets if VIRTIO_NET_F_CTRL_VLAN isn't
negotiated.
>>
>> We should also not send the vlan table to management, this patch makes
>> the vlan-talbe optional.
> ^^^^^^^^^^
> table.
>
> One question I have from the API perspective is can we suddenly change
> something to be optional? If there are any users of this ,
> wouldn't they have to change now to check the existence of this
> list?
You are correct. Since the parameter is an output field, older clients
may be depending on it existing. It is okay to generate an empty array,
but you must not entirely omit the array unless you add further
justification in your commit message that you are 100% positive that
there are no clients of 1.6 that will be broken when the array no longer
appears in the output.
Can you rework the patch to just leave the array empty in the case where
the bit does not indicate it is used? Or do we need to add a new bool
field to the output for new enough management to know whether to use the
array?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-02-17 16:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 2:27 [Qemu-devel] [PATCH] virtio-net: only output the vlan table when VIRTIO_NET_F_CTRL_VLAN is negotiated Amos Kong
2014-02-17 15:27 ` Vlad Yasevich
2014-02-17 16:52 ` Eric Blake
2014-02-17 16:56 ` Eric Blake [this message]
2014-02-17 16:58 ` Vlad Yasevich
2014-02-18 10:06 ` Michael S. Tsirkin
2014-02-18 14:04 ` Vlad Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53023F38.5060406@redhat.com \
--to=eblake@redhat.com \
--cc=akong@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sf@sfritsch.de \
--cc=vyasevic@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).