[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <E4CD12F19ABA0C4D8729E087A761DC350F7ACC30@ORSMSX101.amr.corp.intel.com>
Date: Wed, 14 Oct 2015 14:46:52 +0000
From: "Arad, Ronen" <ronen.arad@...el.com>
To: Jiri Benc <jbenc@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next 1/4] rtnetlink: Add get_link_af_size_filtered
to rtnl_af_ops
>-----Original Message-----
>From: Jiri Benc [mailto:jbenc@...hat.com]
>Sent: Wednesday, October 14, 2015 2:55 AM
>To: Arad, Ronen
>Cc: netdev@...r.kernel.org
>Subject: Re: [PATCH net-next 1/4] rtnetlink: Add get_link_af_size_filtered to
>rtnl_af_ops
>
>On Tue, 13 Oct 2015 22:58:31 -0700, Ronen Arad wrote:
>> --- a/include/net/rtnetlink.h
>> +++ b/include/net/rtnetlink.h
>> @@ -130,6 +130,8 @@ struct rtnl_af_ops {
>> const struct nlattr *attr);
>> int (*set_link_af)(struct net_device *dev,
>> const struct nlattr *attr);
>> + size_t (*get_link_af_size_filtered)(const struct
>net_device *dev,
>> + u32 ext_filter_mask);
>> };
>
>There's not much point in having two callbacks doing essentially the
>same. Why you just don't add the new parameter to the existing
>get_link_af_size? Looking at what the patch 3 does, the current
>implementations of the callback can just ignore the new parameter and
>bridge can remove the current br_get_link_af and rename
>br_get_link_af_size_filtered to br_get_link_af.
[@Ronen] I agree with you about br_netlink. There was no need for both
so I removed br_get_link_af. Changing get_link_af_size signature, however,
will require change in other unrelated locations. I wanted to avoid that. The affected location are:
net/ipv4/devinet.c:2374: .get_link_af_size = inet_get_link_af_size,
net/ipv6/addrconf.c:5868: .get_link_af_size = inet6_get_link_af_size,
If there is a consensus that adding ext_filter_mask argument to
get_link_af is preferred, I'll submit a v2.
>
> Jiri
>
>--
>Jiri Benc
--
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