Removal of deprecation for network_interfaces != AUTO

Doug Barton dougb at
Thu Jun 25 23:48:41 UTC 2009

Brooks Davis wrote:
> So based on the feedback I saw, there were two use cases where there
> wasn't another easy way to do what setting network_interface's.  Yours
> (though I think my suggestion may well work)

My current script is actually a little more complicated than what I
described, since I have 2 different wifi cards, one of which is a
pcmcia card that I use in situations where the built-in card can't
pick up the signal. So my current script tests to see if the wire is
up, and if so it exits. Then it tests to see if the pcmcia card is
inserted, and if so it configures that, and if not it configures the
built-in card.

What you proposed would work in the situation where I only had one
wifi card, but I haven't yet thought through how to refactor the
script in order to allow rc configuration of a non-existent piece of
hardware to fail gracefully.

That said, your idea is a good one, and actually gives me some things
to think about in terms of how to incorporate my concept into the
existing rc system in a "better" way than how I'm doing it now (which
admittedly is kind of a kludge, albeit a functional one).

> and Matthew Seaman's which
> won't actually work in 8.0 without other config changes.  In both cases,
> those uses reflect a failure to support valid use cases which is a good
> reason to leave the ability to set network_interfaces in place.

I'm glad that we agree on that bit at least, and if I haven't already
made it clear if we ever get to a point where network_interfaces is
not needed, I'm happy to see it go.

I would however add to your list the following problems that were
noted in the discussion:

1. The ipv6_network_interfaces/IPv6 autoconfig consolidation problem
2. Auto-loading of kernel modules related to the list of interfaces to
3. The renaming cloned interfaces problem

> That being said I'd still like to see the warning restored because:
>  - It doesn't prevent using these workarounds.
>  - It reduces support issues due to misuse.
>    - Most reported uses were in fact wrong.
>  - Removing network_interfaces will help us move toward a state of more
>    dynamic configuration to better match system realities.

My feeling remains that if it's a valid option it should not produce a
warning (which becomes very very annoying over time). I would also
argue that having the warning didn't buy us anything because all of
the people who were defining network_interfaces kept doing it in spite
of the warning (whether they actually needed to or not).

I do agree with you however that there is an issue of
anti-foot-shooting, and having given some thought to what you said in
regards to the support issues I do have a vague recollection of the
issue you described where people would leave out lo0 and then have big
problems. To that end I offer the attached (admittedly untested atm
because I'm in the middle of something else) patch which I believe
would solve that problem.

I would like to suggest a compromise to leave the warning out of 8.x
until such time as that feature truly is not needed, then do a proper
deprecation of it when that time comes. And remove the functionality
in 9.x. The compromise being that I will agree not to MFC the removal
of the warning to RELENG_[67] so that whatever benefit the warning has
in terms of discouraging users will remain in place.

Sound good?



    This .signature sanitized for your protection

-------------- next part --------------
Index: network.subr
--- network.subr	(revision 195005)
+++ network.subr	(working copy)
@@ -727,6 +727,13 @@
 		_tmplist="${network_interfaces} ${cloned_interfaces}"
+		# Help prevent foot-shooting
+		#
+		case "$_tmplist" in
+		lo0*|*lo0|*' lo0 '*)	;;	# This is fine, do nothing
+		*)	_tmplist="lo0 ${_tmplist}" ;;
+		esac

More information about the freebsd-rc mailing list