Date: Tue, 20 Dec 2011 18:48:40 +0000 From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-current <freebsd-current@FreeBSD.org>, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: r228700 can't dhclient em0 Message-ID: <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> In-Reply-To: <20111220165134.GA68792@lor.one-eyed-alien.net> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77311BF9-BD22-4567-B8FE-9CA0A99D4CA3>