Date: Thu, 25 Jun 2009 20:13:36 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Brooks Davis <brooks@FreeBSD.org> Cc: freebsd-rc@FreeBSD.org Subject: Re: Removal of deprecation for network_interfaces != AUTO Message-ID: <4A443CE0.7050000@FreeBSD.org> In-Reply-To: <20090626023526.GA45597@lor.one-eyed-alien.net> References: <4A21A4F6.5060709@dougbarton.us> <20090601212506.GA2351@lor.one-eyed-alien.net> <20090625225027.GB45036@lor.one-eyed-alien.net> <4A440CD1.4080904@FreeBSD.org> <20090626023526.GA45597@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A443CE0.7050000>