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.
>>=20
>> 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:
>>=20
>> make -C $srcdir/lib/libc install
>> make -C $srcdir/sbin/dhclient install
>> make -C $srcdir/sbin/ifconfig install
>=20

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

--=20
Bjoern A. Zeeb                                 You have to have visions!
         Stop bit received. Insert coin for new address family.=
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"