[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54763AA6.4000804@cumulusnetworks.com>
Date: Wed, 26 Nov 2014 12:40:06 -0800
From: Roopa Prabhu <roopa@...ulusnetworks.com>
To: Stephen Hemminger <stephen@...workplumber.org>
CC: vyasevich@...il.com, netdev@...r.kernel.org,
wkok@...ulusnetworks.com, gospo@...ulusnetworks.com,
jtoppins@...ulusnetworks.com, sashok@...ulusnetworks.com
Subject: Re: [PATCH net-next] bridge: add vlan id to mdb notifications
On 11/26/14, 10:56 AM, Stephen Hemminger wrote:
> On Wed, 26 Nov 2014 05:53:33 -0800
> roopa@...ulusnetworks.com wrote:
>
>> diff --git a/include/uapi/linux/if_bridge.h b/include/uapi/linux/if_bridge.h
>> index da17e45..db061fd 100644
>> --- a/include/uapi/linux/if_bridge.h
>> +++ b/include/uapi/linux/if_bridge.h
>> @@ -185,6 +185,7 @@ struct br_mdb_entry {
>> struct in6_addr ip6;
>> } u;
>> __be16 proto;
>> + __be16 vid;
>> } addr;
>> };
>>
> You can't add fields to existing binary API
Ack, we know the concern..., The fact that it was not changing the size
of the struct (due to existing padding and i verified that it worked
with an older iproute2), we wanted to get the patch out and get some
feedback.
Getting the vlan in the notification is imp and the only other option I
see is to add a new netlink attribute in the mdb msg.
I have always wondered, if binary netlink attributes have this
restriction, they should be discouraged. especially when the other
extensible option is to add them as a separate netlink attribute.
Thanks for the review.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists