Date: Tue, 20 Dec 2011 20:00:27 -0600 From: Brooks Davis <brooks@FreeBSD.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: Doug Barton <dougb@FreeBSD.org>, freebsd-current <freebsd-current@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: r228700 can't dhclient em0 Message-ID: <20111221020027.GF68792@lor.one-eyed-alien.net> In-Reply-To: <20111220192354.GB70684@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> <20111220192354.GB70684@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--K/NRh952CO+2tg14 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote: > Brooks, >=20 > On Tue, Dec 20, 2011 at 10:51:34AM -0600, Brooks Davis wrote: > B> We almost certainly need to back r228571 out. This is not an acceptab= le > B> upgrade path that would be acceptable historically. Specially, we have > B> effectively promised users that an X.Y world will work on an X+1.0 > B> kernel for most of history. There are obvious exceptions to this, but > B> we have never allowed ifconfig to be one of them (I broke it many years > B> ago with my first attempt to add if_epoch to if_data and had to back > B> that out). >=20 > Pardon, where did we promise that? The applications in jail should work, > but not kernel configuration tools. The network facilities like ipfw > and pf has changed their ABI numerous times, making a new kernel > with older world inaccessible via network after boot. We've not promised it in writing, but by not breaking it for many years we're created an effective promise IMO. > Considering r228571: we need to specify vhid as additional address > attribute in atomic manner, via one ioctl(). Address can't be first > configured, and then made redundant, that would lead it to being > static for a short period, sending gratutious ARP announcement, etc. >=20 > An assumption that we are not allowed to change ABI for our own tools > strongly discourages bringing in new features :( I'm not saying we can't change the ABI. I am saying that we should make sure we can support a remote, console-less upgrade from what ever 9.x branches are practical to 10.0 in the average case. We've set the expectation that this will work and IMO it's a reasonable expectation. =20 We've violated it in a few cases such as the emX->igbX fiasco, but by and large most users have been able to do this. I guess I'm ok with dealing with this in HEAD, but I'm not OK with it for all upgrades from 9.x. -- Brooks --K/NRh952CO+2tg14 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFO8T26XY6L6fI4GtQRApWGAJ9pA/Z15kmu+2ga7r7mnWv4jsSN2wCdGlej E0MUDmeTkxV7N/9p9/UuSu0= =nCux -----END PGP SIGNATURE----- --K/NRh952CO+2tg14--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111221020027.GF68792>