HEADSUP: arp-v2 has been committed

[Garrett Cooper]

On Mon, Jan 12, 2009 at 10:25 AM, Li, Qing <qing.li at bluecoat.com> wrote:
> 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@ and -net@ 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

    Oh, btw... wine works well when you set the RTF_LLINFO value to 0
with arp-v2, AFAICT.
-Garrett