RE: HEADSUP: arp-v2 has been committed

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 
both -current_at_ and -net_at_ MLs last month, moving forward, all 
arp-v2 affected ports should continue to be modified and updated 
with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are 
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. 

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_at_pfeifer.com]
> Sent: Friday, January 09, 2009 1:27 AM
> To: Li, Qing
> Cc: Tijl Coosemans; Qing Li; freebsd-net_at_freebsd.org; freebsd-
> current_at_freebsd.org
> Subject: RE: HEADSUP: arp-v2 has been committed
> 
> 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.
> 
> 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?
> 
> 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.)
> 
> > 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.
> 
> Sounds like that is the case?
> 
> > 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.
> 
> 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.
> 
> How are you going to address this?
> 
> Gerald
> --
> Gerald (Jerry) Pfeifer   gerald_at_pfeifer.com
> http://www.pfeifer.com/gerald/