[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181125154555.GA18663@lunn.ch>
Date: Sun, 25 Nov 2018 16:45:55 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc: netdev@...r.kernel.org, roopa@...ulusnetworks.com,
davem@...emloft.net, bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v2 1/3] net: bridge: add support for
user-controlled bool options
On Sat, Nov 24, 2018 at 04:34:20AM +0200, Nikolay Aleksandrov wrote:
> We have been adding many new bridge options, a big number of which are
> boolean but still take up netlink attribute ids and waste space in the skb.
> Recently we discussed learning from link-local packets[1] and decided
> yet another new boolean option will be needed, thus introducing this API
> to save some bridge nl space.
> The API supports changing the value of multiple boolean options at once
> via the br_boolopt_multi struct which has an optmask (which options to
> set, bit per opt) and optval (options' new values). Future boolean
> options will only be added to the br_boolopt_id enum and then will have
> to be handled in br_boolopt_toggle/get. The API will automatically
> add the ability to change and export them via netlink, sysfs can use the
> single boolopt function versions to do the same. The behaviour with
> failing/succeeding is the same as with normal netlink option changing.
>
> If an option requires mapping to internal kernel flag or needs special
> configuration to be enabled then it should be handled in
> br_boolopt_toggle. It should also be able to retrieve an option's current
> state via br_boolopt_get.
>
> v2: WARN_ON() on unsupported option as that shouldn't be possible and
> also will help catch people who add new options without handling
> them for both set and get. Pass down extack so if an option desires
> it could set it on error and be more user-friendly.
>
> [1] https://www.spinics.net/lists/netdev/msg532698.html
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Reviewed-by: Andrew Lunn <andrew@...n.ch>
Andrew
Powered by blists - more mailing lists