Removal of deprecation for network_interfaces != AUTO

[Brooks Davis]

On Thu, Jun 25, 2009 at 04:48:33PM -0700, Doug Barton wrote:
> 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

I don't believe the warning has an effect one way or another on this
issue.  For that matter, a quick grep indicates that setting
network_interfaces should have no impact on IPv6 configuration.

> 2. Auto-loading of kernel modules related to the list of interfaces to
> configure

I continue to believe this "feature" is a mistake.

> 3. The renaming cloned interfaces problem

I know for certain that this isn't a general problem because as I said
in response to that post, it works just find for me.

> > 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?

I truly don't see the point in your proposed compromise.  It fails
to educate users either of a coming change or of their failure to
understand the variable they are setting (usually wrongly.)  The
few people with legitimate uses case easily ignore the error or can
simply delete it from their local copies of the script since they are
presumably using mergemaster or freebsd-update, both of which will let
them preserve the change.

-- Brooks

> Doug
> 
> -- 
> 
>     This .signature sanitized for your protection
> 

> 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
>  		;;
>  	esac
>  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20090626/202f1f40/attachment.pgp