From owner-freebsd-net@FreeBSD.ORG Mon Jan 12 18:25:17 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14631065672; Mon, 12 Jan 2009 18:25:17 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id BED568FC22; Mon, 12 Jan 2009 18:25:17 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n0CIPF8A026583; Mon, 12 Jan 2009 10:25:16 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jan 2009 10:25:12 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HEADSUP: arp-v2 has been committed Thread-Index: AclyPINDLzqKTA8HQUmWbWJoyRt36wCozjMA References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> From: "Li, Qing" To: "Gerald Pfeifer" , Cc: Tijl Coosemans , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Qing Li Subject: RE: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2009 18:25:18 -0000 I have revived the RTF_LLINFO definition in route.h. A new kernel option "COMPAT_ROUTE_FLAGS" is introduced, all for providing binary compatibility for existing ports. I could have made the RTF_LLINFO bit only applicable with _KERNEL. Without rehashing the discussion we all had on this topic on=20 both -current@ and -net@ MLs last month, moving forward, all=20 arp-v2 affected ports should continue to be modified and updated=20 with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are=20 obsolete. There are no support for the semantics of these flag bits in the kernel, other than returning these bits to userland for the existing ports.=20 Please sync-up to the following revision: SVN rev 187094 on 2009-01-12 11:24:32Z by qingli Thanks, -- Qing > -----Original Message----- > From: Gerald Pfeifer [mailto:gerald@pfeifer.com] > Sent: Friday, January 09, 2009 1:27 AM > To: Li, Qing > Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd- > current@freebsd.org > Subject: RE: HEADSUP: arp-v2 has been committed >=20 > On Tue, 30 Dec 2008, Li, Qing wrote: > > I don't think we can provide binary compatibility without putting > > back RTF_LLINFO exactly as it was. My preference is to continue down > > the new path without RTF_LLINFO. >=20 > So, you are saying that applications built on FreeBSD 7 or earlier > that use RTF_LLINFO will no longer work properly on FreeBSD 8 after > your change? >=20 > Ignoring everything else, that would be a killer and the one reason > to definitely change the current situation. Otherwise, ISVs will need > two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and > believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux > distributions do provide this level of compatibility.) >=20 > > We still have some time before the 8.0 release. It's straightforward > > for me to retain some of the RTF_LLINFO support in the new kernel if > > and when the situation becomes necessary. >=20 > Sounds like that is the case? >=20 > > Since the affected ports now have the conditional code around > > RTF_LLINFO, the updates would allow these ports to compile in > > both -current and in the previous releases. >=20 > emulators/wine still is broken, and upstream Wine has not accepted > the patch yet. I believe one reason likely is the above, and the > fact that this may break commercial builds of Wine. >=20 > How are you going to address this? >=20 > Gerald > -- > Gerald (Jerry) Pfeifer gerald@pfeifer.com > http://www.pfeifer.com/gerald/