[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <63AC6A69-F9A1-4A83-8EF7-D897243743B4@cumulusnetworks.com>
Date: Thu, 27 Aug 2015 08:48:09 -0700
From: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To: Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
Cc: "David S . Miller" <davem@...emloft.net>,
Stephen Hemminger <stephen@...workplumber.org>,
bridge@...ts.linux-foundation.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bridge: Add netlink support for vlan_protocol attribute
> On Aug 26, 2015, at 11:00 PM, Toshiaki Makita <makita.toshiaki@....ntt.co.jp> wrote:
>
> This enables bridge vlan_protocol to be configured through netlink.
>
> When CONFIG_BRIDGE_VLAN_FILTERING is disabled, kernel behaves the
> same way as this feature is not implemented.
>
> Signed-off-by: Toshiaki Makita <makita.toshiaki@....ntt.co.jp>
> ---
> include/uapi/linux/if_link.h | 1 +
> net/bridge/br_netlink.c | 34 ++++++++++++++++++++++++++++++++++
> net/bridge/br_private.h | 1 +
> net/bridge/br_vlan.c | 35 +++++++++++++++++++++--------------
> 4 files changed, 57 insertions(+), 14 deletions(-)
>
Nice, looks good. I have a similar patch as well and was going to ask wouldn’t it be
better to make empty stubs which return an error when vlan filtering isn’t configured
and drop the ifdefs in the netlink handling code ?
Similar to how vlan_filtering netlink attribute is handled in commit:
a7854037da00 ("bridge: netlink: add support for vlan_filtering attribute”)
Potential problem would be the return of the protocol, but I think if 0 is returned that
can be handled.
Cheers,
Nik
--
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