Date: Wed, 7 Aug 2013 16:05:58 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Bruce Simpson <bms@fastmail.net> Cc: src-committers@freebsd.org, "Alexander V. Chernikov" <melifaro@FreeBSD.org>, svn-src-all@freebsd.org, Hiroki Sato <hrs@FreeBSD.org>, svn-src-head@freebsd.org, Rui Paulo <rpaulo@FreeBSD.org> Subject: Re: svn commit: r253841 - head/sys/netinet6 Message-ID: <20130807120558.GF20104@FreeBSD.org> In-Reply-To: <52022217.50709@fastmail.net> References: <201307311624.r6VGOob5022079@svn.freebsd.org> <20130801142324.GG20104@FreeBSD.org> <97527D06-7783-4441-BA50-702DEE0B9076@FreeBSD.org> <51FA8C73.4070808@FreeBSD.org> <A664BEC8-6EC5-49AD-AC1A-FA1CB0603925@FreeBSD.org> <52022217.50709@fastmail.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 07, 2013 at 11:31:51AM +0100, Bruce Simpson wrote: B> On 01/08/13 17:55, Rui Paulo wrote: B> > On 1 Aug 2013, at 09:27, Alexander V. Chernikov <melifaro@FreeBSD.org> wrote: B> >> Because thay aren't really interfaces. All they need is BPF. B> >> There is a cleaner approach described here: http://lists.freebsd.org/pipermail/freebsd-net/2012-December/034031.html B> > B> > I don't agree with this patch as-is, but I'll need to spend some time writing an email... To be continued later. B> > B> B> +1 with Rui here. A few comments. B> B> I would like to see a cleaner approach to the networking data plane, but B> this would need to be considered in some depth. One place to start might B> be the "informational" RFC for the Netlink socket API. B> B> Whilst the gap between BPF and ifnet is acknowledged, there is still a B> place for "virtual" interfaces. Lacking other management mechanisms, the B> ifnet (and its name) ends up being used as a convenient handle. B> B> I have code in development which tries to address more general issues of B> IPvX address dependency by using such an interface. Yes, lack of good management mechanism creates a temptation to create a foo(4) interface for any new FOO protocol, with its own if_ioctl method that will provide a clean entry into its management. I suspect that was one of the reasons to implement carp(4) as interface. What do you mean about "virtual" interfaces? An interface must represent a sink where a route entry can point to and incoming packets can come in. With this definition a vlan(4) is a real interface, but pfsync(4), pflog(4), ipfwlog(4) are not. The situation with lack of management mechs should be fixed, and BPF providers should be decoupled from ifnet, and no new not-a-true-interface ifnets should be introduced in FreeBSD. All these not-a-true-interfaces require dozens of special handling around the kernel, an example is a commit we are discussing. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807120558.GF20104>