From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:23:56 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F6EF106566B; Tue, 20 Dec 2011 19:23:56 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id AE73C8FC1B; Tue, 20 Dec 2011 19:23:55 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id pBKJNshl071360; Tue, 20 Dec 2011 23:23:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBKJNsYd071359; Tue, 20 Dec 2011 23:23:54 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2011 23:23:54 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111220165134.GA68792@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Doug Barton , freebsd-current , Dimitry Andric Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 19:23:56 -0000 Brooks, 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 acceptable 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). 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. 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. An assumption that we are not allowed to change ABI for our own tools strongly discourages bringing in new features :( -- Totus tuus, Glebius.