From owner-freebsd-rc@FreeBSD.ORG Mon Oct 5 23:18:42 2009 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01BB51065670; Mon, 5 Oct 2009 23:18:42 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D5DE18FC0A; Mon, 5 Oct 2009 23:18:41 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n95MvHNt018431; Mon, 5 Oct 2009 15:57:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Oct 2009 15:56:36 -0700 Message-ID: In-Reply-To: <4ACA71D4.6010502@FreeBSD.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration Thread-Index: AcpGCoKEgAr2qKR3TbeREfjG/EmULwAASLlw References: <200909122222.n8CMMV3d099311@svn.freebsd.org> <4AB15FCE.70505@FreeBSD.org> <20090920.224018.16368211.hrs@allbsd.org><20091005.123427.227628092.hrs@allbsd.org> <4ACA71D4.6010502@FreeBSD.org> From: "Li, Qing" To: "Doug Barton" , "Hiroki Sato" , Cc: freebsd-current@freebsd.org, freebsd-rc@freebsd.org Subject: RE: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 23:18:42 -0000 I agree with Doug and I'd prefer getting more runtime cycles out of these changes before MFC into stable/8.=20 On a semi-related topic, I like the features developed in r197138. The changes are significant enough that having a MFC of 3 days is way too short. This changelist should also be postponed to post REL_8. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Doug Barton > Sent: Monday, October 05, 2009 3:23 PM > To: Hiroki Sato > Cc: freebsd-current@freebsd.org; freebsd-rc@freebsd.org > Subject: Re: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration >=20 > Hiroki Sato wrote: > > Hi, > > > > I would like your comments about merging the network_ipv6 -> netif > > integration to stable/8. >=20 > I maintain my objection to MFC'ing this prior to the 8.0-RELEASE. As > stated previously my objections are as follows (in decreasing order of > general importance): >=20 > 1. It is a fairly significant change happening too late in the release > cycle. IMO that is reason enough to not allow the change. > 2. Although 8.0 seems to be getting more beta/rc testing than previous > .0 releases, the overall number of users testing it is still a small > percentage of the userbase. > 3. A dramatically smaller percentage of those users who are actually > doing the testing is also using IPv6. > 4. There are still rough edges to the changes. > 5. I personally disagree with some of the choices you've made and > would like to see more discussion about them. (More about 4 and 5 > below.) >=20 > The rough edges I've noticed have to do with the various problems > people have reported to the lists, including what seems to be a lack > of testing without IPv6 in the kernel, continuing evolution of how to > deal with the afnet tests, and personally I've noticed the following > on my console, although I haven't had time to research yet whether > it's definitely coming from your changes: >=20 > in6_ifattach_linklocal: failed to add a link-local addr to wpi0 >=20 > In terms of design decisions you've made, I am still confused about > why you insist on deprecating ipv6_enable. Recent discussion on the > lists indicates to me that I'm not alone in thinking that this is a > valuable mechanism and that there is not only no reason to deprecate > it, to do so is not desirable. >=20 > I'd also like to explore further the idea that I suggested in a > previous thread that it should not be necessary to specify > ifconfig_IF_ipv6 at all. The vast majority of users will be using RA > for the next couple of years at least, so in my mind it makes sense to > default to using ipv6_network_interfaces=3D$network_interfaces and RA = by > default. If the user has a need to configure something explicitly then > you've provided the mechanism for them to do that, but they shouldn't > be forced to use it. This is another reason that I think ipv6_enable > should be the "master" knob. I like the idea of the ipv6_prefer knob, > but I do not like the idea of overloading it with the function of > ipv6_enable too. >=20 > I can certainly understand why you are eager to get these changes into > 8.0, however if we do a proper job of maintaining backwards > compatibility (which I think we should do anyway) I don't see any > reason that they cannot be merged after 8.0, and more importantly > after they have had a proper opportunity to shake out in HEAD. >=20 >=20 > Doug >=20 > -- >=20 > This .signature sanitized for your protection >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org"