On Tue, Sep 25, 2018 at 2:34 AM, Patrick Ruddy <pru...@vyatta.att-mail.com> wrote: > On Wed, 2018-09-19 at 21:47 -0700, David Ahern wrote: >> On 9/18/18 6:12 AM, Patrick Ruddy wrote: >> > >> > I've hit a small snag with adding the new groups. The number of defined >> > groups currently sits at 31 so I can only add one before hitting the >> >> I believe you have no more available. RTNLGRP_* has been defined from 0 >> (RTNLGRP_NONE) to 31 (RTNLGRP_IPV6_MROUTE_R) which covers the u32 range. >> >> > limit defined by the 32 bit groups bitmask in socakddr_nl. I can use 1 >> > group for both v4 and v6 notifications which seems like the sensible >> > options since the AF is carried separately, but it breaks the precedent >> > where there are separate IPV4 and IPV6 groups for IFADDR. >> > >> > I have the combined group patches ready and can share them if that's >> > the preference. >> > >> > Has there been any previous discussion about extending the number of >> > availabel groups? >> > >> >> I have not tried it, but from a prior code review I believe you have you >> use setsockopt to add groups > 31. > > I can certainly join the new groups using setsockopt and > NETLINK_ADD_MEMBERSHIP. > I can't see any examples of extending the defined group list within the > kernel so I assume I just add to the RTNLGRP enum list with a suitable > comment to indicate that later groups must be joined with the mechanism > above or am I missing some other way of dynamically adding groups? >
With a quick look, there are other subsystem specific groups: xfrm_nlgroups, nfnetlink_groups ...which i see apps registering using NETLINK_ADD_MEMBERSHIP. seems like an overkill to add something like this for your case. yet another option to consider: use family: RTNL_FAMILY_IPMR/ RTNL_FAMILY_IP6MR with RTM_GETADDR/DELADDR and use the existing groups: RTNLGRP_IPV4_IFADDR / RTNLGRP_IPV6_IFADDR (pls check if this will break any existing users) precedence is ipmr fib rules.