Removal of deprecation for network_interfaces != AUTO

Brooks Davis brooks at
Fri Jun 26 14:53:04 UTC 2009

I give.  I think this change was wrong both technically and
procedurally, but it's wasted enough of my time and energy that that I
don't want to pursue it further.

-- Brooks

On Thu, Jun 25, 2009 at 08:13:36PM -0700, Doug Barton wrote:
> Brooks Davis wrote:
> > 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.
> If we're going to move forward on feature parity for IPv4 and IPv6
> then we need to take that issue seriously.
> >> 2. Auto-loading of kernel modules related to the list of interfaces to
> >> configure
> > 
> > I continue to believe this "feature" is a mistake.
> I find it quite handy personally. Unless I'm missing something the
> alternative would be to require people to kldload a module before
> doing 'ifconfig up' which seems kind of silly, and I think would be a
> regression our users would object to.
> >> 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.
> It was general enough for one user to complain about it, and state
> that the only alternative for him was to use the network_interfaces
> option. If the bug can be confirmed and subsequently fixed, fine.
> >>> 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. 
> I don't see any point in a warning message for the deprecation of an
> option that is still needed by our users until such time as it is no
> longer actually needed. I obviously don't share your enthusiasm for
> removing it, and I haven't seen anyone else chime in with a good
> reason to remove it either.
> The one concern you've raised about this option which does seem
> legitimate is the issue of users forgetting to include lo0 in their
> list, which I've addressed.
> Doug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-rc mailing list