r228700 can't dhclient em0
Gleb Smirnoff
glebius at FreeBSD.org
Wed Dec 21 12:55:42 UTC 2011
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.
More information about the freebsd-current
mailing list