Re: r228700 can't dhclient em0

  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_at_ 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.