Re: r228700 can't dhclient em0

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?

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

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.

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

/bz

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