From owner-svn-src-all@FreeBSD.ORG Tue Nov 25 22:41:04 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 120C0AB0; Tue, 25 Nov 2014 22:41:04 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A5AAC272; Tue, 25 Nov 2014 22:41:03 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sAPMf1B9074833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2014 14:41:02 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sAPMf1x6074832; Tue, 25 Nov 2014 14:41:01 -0800 (PST) (envelope-from jmg) Date: Tue, 25 Nov 2014 14:41:01 -0800 From: John-Mark Gurney To: Gleb Smirnoff , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r274966 - head/sys/net Message-ID: <20141125224101.GK99957@funkthat.com> References: <201411241400.sAOE0Srq063100@svn.freebsd.org> <20141124194022.GR47144@FreeBSD.org> <20141124201821.GY95784@rincewind.trouble.is> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141124201821.GY95784@rincewind.trouble.is> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 25 Nov 2014 14:41:02 -0800 (PST) X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 22:41:04 -0000 Philip Paeps wrote this message on Mon, Nov 24, 2014 at 21:18 +0100: > On 2014-11-24 22:40:22 (+0300), Gleb Smirnoff wrote: > > On Mon, Nov 24, 2014 at 02:00:28PM +0000, Philip Paeps wrote: > > P> Author: philip > > P> Date: Mon Nov 24 14:00:27 2014 > > P> New Revision: 274966 > > P> URL: https://svnweb.freebsd.org/changeset/base/274966 > > P> > > P> Log: > > P> Add a sysctl `net.link.tap.deladdrs_on_close' to configure whether tap > > P> should delete configured addresses and routes when the interface is > > P> closed. Default is enabled (preserve current behaviour). > > P> > > P> MFC after: 1 week > > > > Any time I see yet another sysctl knob added I ask myself: what if I want > > this feature on tap0 but doesn't want it on tap1? What if want it on host, > > but doesn't want it on vmnet-enabled jail? Where from could I learn about > > this sysctl if I am not subscribed to svn-src-*@? > > I admit that this one was a hack written in anger a while back. When I > hacked this, I was struggling with a bunch of bhyve instances with > fiddly point to point routes and every time I restarted a bhyve, I'd > have to fix my routing table again. That got frustrating quickly. Not > an excuse. Just an explanation. > > > Of course adding a sysctl knob is faster and easier for a FreeBSD hacker. > > But is it a better for a FreeBSD user? Are we making OS for just ourselves? > > > > Look, we've got tapifioctl(). If you are too lazy to introduce new > > ioctl command and code it support in ifconfig, in this case you can just > > use any of IFF_LINK0, IFF_LINK1, IFF_LINK2 flag to toggle this feature > > via SIOCSIFFLAGS. And then document it in tap(4). > > Note that I semi-purposely didn't document this in tap(4). I should > have pointed that out in the commit message, sorry. When I wrote this, Can you update the description of the sysctl? That way when we want to remove it, we can... Any sysctl that makes a release is an API that we need to provide compatibility for... :( -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."