Re: r228700 can't dhclient em0

On Tue, Dec 20, 2011 at 06:48:40PM +0000, Bjoern A. Zeeb wrote:
> On 20. Dec 2011, at 16:51 , Brooks Davis wrote:
> 
> > On Tue, Dec 20, 2011 at 04:43:21PM +0100, Dimitry Andric wrote:
> >> On 2011-12-20 09:38, Doug Barton wrote:
> >> ...
> >>> I tried replacing both ifconfig and dhclient with the versions that were
> >>> built along with the new kernel, and that didn't work.
> >> 
> >> Looking at the changes in r228571, it seems they also affect libc, so
> >> installing that is probably also needed.  Since all my test systems are
> >> already upgraded to post-r228571, can somebody please confirm it works
> >> after doing:
> >> 
> >> make -C $srcdir/lib/libc install
> >> make -C $srcdir/sbin/dhclient install
> >> make -C $srcdir/sbin/ifconfig install
> > 
> 
> Depends on what you are trying to achieve.  There is more software affected.
> 
> > We almost certainly need to back r228571 out.  This is not an acceptable
> > upgrade path that would be acceptable historically.  Specially, we have
> > effectively promised users that an X.Y world will work on an X+1.0
> 
> I am not sure we supported that but X.<latest> to X+1.Y maybe?

That's the guarantee we've advertised, but the breakage we've supported
has mostly been for more narrowly focused tools that grovel around in
KVM space.  We've usually allowed an old world to work with only a few
shims (ps for instance).  Adding a new ifconfig to the list would be an
expansion there.

I also worry about the problem that once you've installed world there is
no easy way back.

> > kernel for most of history.  There are obvious exceptions to this, but
> > we have never allowed ifconfig to be one of them (I broke it many years
> > ago with my first attempt to add if_epoch to if_data and had to back
> > that out).
> 
> There is a couple of issues here.
> 
> The one that's on me is struct ifa_msghdr / getifaddrs() and the problem here
> is that software incl. getifaddrs() doesn't use the in structs embedded lengths
> in first place.  In if_data only a spare was reused, so no changes there.
> That's certainly something we can and should fix in 9 before 10.0 will happen.
> If that was the problem back then, it's certainly a pity it wasn't fixed as
> we wouldn't have that problem these days then.  It would allow appending more
> stuff.

It would nice to fix, but allowing append to if_data means reving the
routing socket API.  I looked at it a bit and then gave up because there
were too many consumers (many out of tree), pretty much all of which
ignore the version number.  I didn't have time to rev the whole API
which is probably where the bar is for breaking the API.

> For the appended int to ifaliasreq, in_aliasreq, in6_aliasreq I haven't
> looked at the actual problem in the upgrade paths.  I guess it's not much
> outside of ifconfig and probably ppp at least for the in_ in6_ variants.

Those many have few enough consumers that we can come up with a
reasonable path forward.

> Backing r228571 out completely will be harder with every change glebius commits
> on top.  So if we think it'll be needed we should stop those commits now and
> think first.
> 
> Just breaking carp and backing out the user space API parts is only a usable
> path with a plan B on how to fix carp as well in the same go really.
> 
> Ingoring 9.0 -> 10-CURRENT or an update on HEAD (neither of which is not a
> normal user upgrade path an supported) I am still wondering how much of that
> can be mitigated and if it might make sense to ponder that direction (also
> for further future changes for sure to happen) to not be stuck forever?
> I fear we'll see/want to do more of these kinds as more people look at the
> if/ll layer...

If we can identify all the changed interfaces and we can teach 9-STABLE
to deal with them then this change is probably OK and we just need to
do the appropriate libc and ifconfig spackling and merge it.  We can't
let this slide too long though because the current state requires an
installkernel+installworld for all intents and purposes and that means
that if the kernel is broken you are dead in the water.

I agree we could really use some sort of way forward that increases our
abilty to make these sorts of changes.

- Brooks

> /bz
> 
> -- 
> Bjoern A. Zeeb                                 You have to have visions!
>          Stop bit received. Insert coin for new address family.
>