svn commit: r253841 - head/sys/netinet6

[Gleb Smirnoff]

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 at 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.