From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 12:55:41 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 F0B2C106564A; Wed, 21 Dec 2011 12:55:41 +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 667668FC14; Wed, 21 Dec 2011 12:55:41 +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 pBLCte4G079069; Wed, 21 Dec 2011 16:55:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id pBLCteoS079068; Wed, 21 Dec 2011 16:55:40 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 21 Dec 2011 16:55:40 +0400 From: Gleb Smirnoff To: Brooks Davis Message-ID: <20111221125539.GF70684@glebius.int.ru> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20111221015241.GE68792@lor.one-eyed-alien.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current , Doug Barton , 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: Wed, 21 Dec 2011 12:55:42 -0000 Brooks, On Tue, Dec 20, 2011 at 07:52:41PM -0600, Brooks Davis wrote: B> While this is the documented path, it's not actually been required B> except in edge cases for ages (the last I can remember is a.out->elf). B> It's been long enough that I don't think we can really make people do B> it except for a short period of time in HEAD. I believe it's B> unacceptable for a release to release upgrade. I have provided API compatibility in r228768. I have tested it with an ifconfig binary taken from 9.0 installation. I hope, this change would satisfy you, and you won't say that "We almost certainly need to back r228571 out". The in_control() and in6_control() are getting more and more hairy :( I'd eager to remove the shim in the 11.x timeline. Since subject mentions "dhclient", I must notice that the dhclient-script always relied on a bug in in_control(). The bug was fixed here: http://svnweb.freebsd.org/base?view=revision&revision=228313 Later the dhclient-script was fixed: http://svnweb.freebsd.org/base?view=revision&revision=228463 So, if we are claiming for an undocumented but important feature that new kernel being capable to configure network with world from a previous major release, then I should merge r228463 right now to stable/9, and not merge r228313. If I don't merge r228463 before 9.0-RELEASE is out, then in 2 years, 10.x-RELEASE kernel won't bring network up via DHCP with world from 9.0-RELEASE. Thus, should I now either bribe re@ to push r228463 prior to release, either back out the bugfix: r228463. Also, backing out r228463 would require backing out a larger work: r228455. Hey, this policy greatly discourages hacking on bugs and new features... :( -- Totus tuus, Glebius.