Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 5 Oct 2009 15:56:36 -0700
From:      "Li, Qing" <qing.li@bluecoat.com>
To:        "Doug Barton" <dougb@freebsd.org>, "Hiroki Sato" <hrs@freebsd.org>, <qingli@freebsd.org>
Cc:        freebsd-current@freebsd.org, freebsd-rc@freebsd.org
Subject:   RE: nd6 change and rc.d/network_ipv6 -> rc.d/netif integration
Message-ID:  <B583FBF374231F4A89607B4D08578A43057E5315@bcs-mail03.internal.cacheflow.com>
In-Reply-To: <4ACA71D4.6010502@FreeBSD.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B583FBF374231F4A89607B4D08578A43057E5315>