Date: Wed, 21 Dec 2011 16:55:40 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Brooks Davis <brooks@FreeBSD.org> Cc: freebsd-current <freebsd-current@FreeBSD.org>, Doug Barton <dougb@FreeBSD.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: r228700 can't dhclient em0 Message-ID: <20111221125539.GF70684@glebius.int.ru> In-Reply-To: <20111221015241.GE68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <20111220191520.GA70684@FreeBSD.org> <20111221015241.GE68792@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111221125539.GF70684>