Re: r228700 can't dhclient em0

On Tue, Dec 20, 2011 at 11:23:54PM +0400, Gleb Smirnoff wrote:
>   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.

We've not promised it in writing, but by not breaking it for many years
we're created an effective promise IMO.

> 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 :(

I'm not saying we can't change the ABI.  I am saying that we should
make sure we can support a remote, console-less upgrade from what ever
9.x branches are practical to 10.0 in the average case.  We've set the
expectation that this will work and IMO it's a reasonable expectation.  
We've violated it in a few cases such as the emX->igbX fiasco, but by
and large most users have been able to do this.  I guess I'm ok with
dealing with this in HEAD, but I'm not OK with it for all upgrades from
9.x.

-- Brooks