> To clarify: every I mentioned in my previous email was about possible > follow-ups - not to be included here.
Understood, I will send them as separate patches. > My understanding is that there is sort of a pending/implicit question > from Jakub on v9: why are you doing this? is does it solve some > specific scaling problem or is 'nl is nicer" thing? I think the motivation question was on the v5 thread, and I replied there as well. My original motivation is to simplify some userspace hardware offload code I am working on, and to finish moving "ip maddr" to netlink. RTM_GETMULTICAST already reports IPv4 and IPv6 group memberships with IFA_MC_USERS. dev->mc is the only part of the multicast state still available only from /proc/net/dev_mcast, so every consumer that needs the full picture keeps two paths: netlink for L3 and procfs text parsing for L2. The offload code above is one such consumer. iproute2 is another: "ip maddr show" already gets IPv4/IPv6 over netlink but still parses procfs for its link-layer entries. The iproute2 change to drop that is ready to follow this series. Also, compared to procfs, the dump provides a nicer API: it supports per-device filtering, other netns through IFA_TARGET_NETNSID, and reports concurrent changes with NLM_F_DUMP_INTR. Thanks, Yuyang
