Date: Mon, 12 Jan 2009 10:25:12 -0800 From: "Li, Qing" <qing.li@bluecoat.com> To: "Gerald Pfeifer" <gerald@pfeifer.com>, <erwin@freebsd.org> Cc: Tijl Coosemans <tijl@ulyssis.org>, freebsd-net@freebsd.org, freebsd-current@freebsd.org, Qing Li <qingli@freebsd.org> Subject: RE: HEADSUP: arp-v2 has been committed Message-ID: <B583FBF374231F4A89607B4D08578A4302CDB052@bcs-mail03.internal.cacheflow.com> In-Reply-To: <alpine.LSU.1.99.0901091021370.12007@acrux.dbai.tuwien.ac.at> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> <alpine.LSU.1.99.0812290925070.23595@acrux.dbai.tuwien.ac.at> <B583FBF374231F4A89607B4D08578A4302B1CAC5@bcs-mail03.internal.cacheflow.com> <alpine.LSU.1.99.0901091021370.12007@acrux.dbai.tuwien.ac.at>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B583FBF374231F4A89607B4D08578A4302CDB052>