Date: Sat, 21 Feb 2015 03:50:51 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Bruce Simpson <bms@fastmail.net> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r279028 - in head/usr.sbin: . ifmcstat Message-ID: <20150221005051.GT15484@FreeBSD.org> In-Reply-To: <54E6A68B.1090609@fastmail.net> References: <201502192242.t1JMgY3e045902@svn.freebsd.org> <54E6A68B.1090609@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce, On Fri, Feb 20, 2015 at 03:14:19AM +0000, Bruce Simpson wrote: B> Gleb, B> B> Correct me if I'm wrong -- but doesn't this set of changes remove the B> ability for the user to see the stack-wide membership filters on each B> link? The implementation required KVM as it must inspect the SSM filters B> themselves to obtain this information. Can you point me at the code please? I see that both kvm(3) or API based code call in6_ifinfo() or in_ifinfo(). May be you refer to code that was always under #if 0, disabled due to difficulty to go through RB-trees via kvm(3)? B> On 19/02/2015 22:42, Gleb Smirnoff wrote: B> > Now that IGMP and MLD sysctls provide a clean API structures that do not B> > leak kernel internal stuff, reconnect ifmcstat(1) back to build. B> B> The change is well motivated, but the job is only half done. B> B> The backend code you have added simply reflects the per-link information B> to userland as a flat data structure; it does not appear to report what B> the membership filters are. B> B> This would require taking a lock, walking the RB-tree for the in-mode B> filters, and serializing the data to userland as a variable length B> structure. I can do that, if you provide me with details. But I'd really appreciate, if you do that :) -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150221005051.GT15484>