svn commit: r274966 - head/sys/net

[Philip Paeps]

On 2014-11-24 22:40:22 (+0300), Gleb Smirnoff <glebius at FreeBSD.org> 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,
this summer, I meant to ask about the magical and very legacy-looking
VMware vmnet hacks in the driver.  Are those still relevant?  Is there
still a VMWare port that relies on this?  What about the comment that
legacy devfs cloning interferes with ssh(1) (added seven years ago), is
that still true?

> Finally, if later some developer comes and does it in a proper way, then
> he would have a burden of supporting your sysctl for backwards compatibility,
> because you very quickly MFCed it.
> 
> P.S. I am sorry if my email sounds like old man's grumbling.

No problem.  I'm happy to fix this 'better'.  Old men often grumble
sense (I keep telling myself as I get older...).

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information