Date: Fri, 26 Jun 2009 09:51:59 -0500 From: Brooks Davis <brooks@FreeBSD.org> To: Doug Barton <dougb@FreeBSD.org> Cc: Brooks Davis <brooks@FreeBSD.org>, freebsd-rc@FreeBSD.org Subject: Re: Removal of deprecation for network_interfaces != AUTO Message-ID: <20090626145159.GC52107@lor.one-eyed-alien.net> In-Reply-To: <4A443CE0.7050000@FreeBSD.org> 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> <4A443CE0.7050000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 cas= es, > >>> those uses reflect a failure to support valid use cases which is a go= od > >>> 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 > >=20 > > 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. >=20 > If we're going to move forward on feature parity for IPv4 and IPv6 > then we need to take that issue seriously. >=20 > >> 2. Auto-loading of kernel modules related to the list of interfaces to > >> configure > >=20 > > I continue to believe this "feature" is a mistake. >=20 > 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. >=20 > >> 3. The renaming cloned interfaces problem > >=20 > > 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. >=20 > 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. >=20 > >>> 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 mo= re > >>> 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? > >=20 > > I truly don't see the point in your proposed compromise.=20 >=20 > 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. >=20 > 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. >=20 > Doug >=20 --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKROCOXY6L6fI4GtQRApTnAJ9h/NIdPMQsGDvXRsFKz3SWdwr2owCgw+gn Hy1Tkc2BBOyWemxRvNJGFsI= =iehk -----END PGP SIGNATURE----- --m51xatjYGsM+13rf--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090626145159.GC52107>