From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 18:48:45 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D0D106566C; Tue, 20 Dec 2011 18:48:45 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 485488FC08; Tue, 20 Dec 2011 18:48:45 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 6B27E25D385D; Tue, 20 Dec 2011 18:48:44 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 98F38BD76B6; Tue, 20 Dec 2011 18:48:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 5l7X95eJN6db; Tue, 20 Dec 2011 18:48:42 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0E855BD76B5; Tue, 20 Dec 2011 18:48:41 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20111220165134.GA68792@lor.one-eyed-alien.net> Date: Tue, 20 Dec 2011 18:48:40 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <77311BF9-BD22-4567-B8FE-9CA0A99D4CA3@FreeBSD.org> References: <4EEF0124.4000902@FreeBSD.org> <4EEF3B22.8010401@FreeBSD.org> <4EF0499D.4070000@FreeBSD.org> <4EF0AD19.2000603@FreeBSD.org> <20111220165134.GA68792@lor.one-eyed-alien.net> To: Brooks Davis X-Mailer: Apple Mail (2.1084) Cc: freebsd-current , Gleb Smirnoff Subject: Re: r228700 can't dhclient em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 18:48:46 -0000 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. 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.=