From owner-svn-src-head@FreeBSD.ORG Wed Aug 7 20:24:00 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3BAF3EB6; Wed, 7 Aug 2013 20:24:00 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E718526E7; Wed, 7 Aug 2013 20:23:59 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 79601209CC; Wed, 7 Aug 2013 16:23:58 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Wed, 07 Aug 2013 16:23:58 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=D43FLWAZ0NsHBxlMMjetNPcQXow=; b=GP12Vt1lDQ0aAZMjxWGxJnMky0Ny z4SEfOQuhrMjDEgsquXYb6PSKIbr4ahkSwDbX2f6IZkD3MnsOlANSSF0Hisfzqgs H99gZRk9Rm6M1MWzUiJGGa3zwVcglHQEnoByH9KqR5YJrq+c9HDl3ilB+WmKqWeM +i6Pfi0l5OUb3kM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=D43FLWAZ0NsHBxlMMjetNP cQXow=; b=KGdzFo7iS31Z0VEPw30kSSl+TlNt28vyynv0nYdtVQlE0Zz6hBcl/d xxjAg5L531FmNmbXgYq3byeD8xUvGmGzcRfn9PgNK1EZISOT8Fzx4OnrjkKYLbKp PbRWpyO3VYJWmlszObVK7Ga8kKWe7f6FiMDqnIKz4ptbdtmz2T8VQ= X-Sasl-enc: uQXt44g8Hs57+2VY9qOL2FOsC/divyU2rF6HHL4ASF27 1375907037 Received: from [10.101.1.23] (unknown [176.12.107.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 058EAC00E86; Wed, 7 Aug 2013 16:23:53 -0400 (EDT) Message-ID: <5202ABE1.2020400@fastmail.net> Date: Wed, 07 Aug 2013 21:19:45 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: svn commit: r253841 - head/sys/netinet6 References: <201307311624.r6VGOob5022079@svn.freebsd.org> <20130801142324.GG20104@FreeBSD.org> <97527D06-7783-4441-BA50-702DEE0B9076@FreeBSD.org> <51FA8C73.4070808@FreeBSD.org> <52022217.50709@fastmail.net> <20130807120558.GF20104@FreeBSD.org> In-Reply-To: <20130807120558.GF20104@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: src-committers@freebsd.org, "Alexander V. Chernikov" , svn-src-all@freebsd.org, Hiroki Sato , svn-src-head@freebsd.org, Rui Paulo X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:24:00 -0000 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.)