Date: Wed, 19 Apr 2023 03:30:18 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235920] ifconfig: unable to create another interface after renaming the previous one with the same name Message-ID: <bug-235920-7501-xXxaDKKcKL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235920-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-235920-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235920 Kyle Evans <kevans@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevans@freebsd.org --- Comment #5 from Kyle Evans <kevans@freebsd.org> --- (In reply to Zhenlei Huang from comment #4) > When an interface is renamed, its unit number is not `freed` and thus lea= d this problem. Right, as soon as you start renaming the concept of a unit number can so ea= sily fade away that it's not worth the complexity trying to manage it. # ifconfig tun0 name sillytun I suddenly have no unit number because there's not such a constraint on nam= es, and imposing one would seem to be a bit weird. At some point, you converge = on restricting renames to maintaining the common prefix so that, e.g., tun0 -> openvpn0 (bad example, but you can see where I'm going with this) wouldn't = be be possible because you don't want to maintain the arbitrary "openvpn" or whatever unr space as well. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235920-7501-xXxaDKKcKL>