Date: Wed, 07 Aug 2013 21:19:45 +0100 From: Bruce Simpson <bms@fastmail.net> To: Gleb Smirnoff <glebius@FreeBSD.org> 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: <5202ABE1.2020400@fastmail.net> In-Reply-To: <20130807120558.GF20104@FreeBSD.org> 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> <20130807120558.GF20104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/08/13 13:05, Gleb Smirnoff wrote: > 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. My concern is that whilst the BPF change is well intentioned, we may be unravelling a loose thread; other issues loom in the FreeBSD network stack elsewhere. These might be considered artefacts of FreeBSD's fairly informal approach to network stack management. This approach has served us reasonably well for many years -- it is simple and easier to maintain than the somewhat byzantine NDIS/TDI sandwich in Microsoft Windows. This doesn't change the fact that dealing with the venerable PF_ROUTE socket is a royal pain. However we should be careful with refactoring. Changes to network stack management may affect stack elements such as net-snmp, snort, ntop, Netflow collectors, etc. A managed infrastructure might also use SNMP to track network configuration data. I foresee that this change could help in those deployment scenarios; as SNMP is platform agnostic, Netdot (and other management tools) must parse and filter out the "non-proto-bound" ifnets (*) as their statistics are not normally considered useful. In Netdot, a set of heuristics are applied based on the sysObjectID MIB variable. (*) It's entirely possible someone may want to log these things for development purposes, though. > > 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. At the moment we have a model whereby protocol families get bound to ifnets statically (not dynamically). It's OK for ifnets to be in a state of change where they may not have protocols bound to them during early system boot. (I guess my question is: packet sockets - why not?) The specific case I am working with does satisfy this criterion, however it relies on other changes which restore the legacy BSD behaviour where loopback traffic will only appear on the BPF instance specific to the ifnet. E.g. currently FreeBSD will present all locally looped back traffic on lo0 (or the current vnet's "primary" lo(4) instance). > > 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. > Agreed. carp(4) does not quite fit the model well at all. FreeBSD's implementation of it relies on ipprotosw[] and some other hooks in ether(4) leading to nested conditionals (my import of M_PROMISC from NetBSD around 2007 may have helped limit code churn here.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5202ABE1.2020400>