Re: HEADSUP: arp-v2 has been committed

On Saturday 27 December 2008 21:21:25 Qing Li wrote:
> Right now I am also a bit leaning towards reintroducing
> the RTF_LLINFO flag bit. This is mainly due to the recent
> discovery of the "route" command issued with the
> "-iface/-interface" option, which conflicts with the
> way how "arp" and "ndp" is handled in the kernel.
> 
> I renamed this flag bit to RTF_LLDATA because only the
> "arp" and "ndp" commands need it.

I wouldn't rename it. That breaks old code just the same.

>> I didn't want to speak up because I'm no authority in this 
>> area and in the end I'm OK with any outcome, but personnaly I 
>> find special-casing {NET_RT_FLAGS,0} to retrieve the L2 
>> entries a bit odd.
> 
> As I've indicated previously, a few ports already have the
> #ifdef RTF_LLINFO block around the sysctl() setup code. 
> Perhaps it's because these ports (such as Wine) run on OS
> that does not support RTF_LLINFO (e.g. Linux?) ?

That's odd, because a quick google shows that for instance NetBSD,
OpenBSD, DragonFly and Mac OS X all define this flag.

Linux is completely different. It doens't use sysctl(3). You have to
read /proc/net/arp and /proc/net/route.

>> Surely, letting {NET_RT_FLAGS,RTF_LLINFO} 
>> return L2 entries is exactly the same to implement, is far 
>> more descriptive, is fully backwards compatible and 
>> compatible with other sysctl operating systems like the other 
>> BSDs and Mac OS X, which helps portability.
> 
> I believe all of the affected ports have been updated to 
> include the conditional blocks around RTF_LLINFO. So 
> there is still a level of compatibility, right ?

Yes, and I'm OK with this. It's just that this makes FreeBSD 8
a special case.

>> AFAIK, the other use of RTF_LLINFO was to filter out L2 
>> entries from the entire L2+L3 routing table to obtain just 
>> the L3 entries. Because the L2 and L3 table have been 
>> separated this filtering isn't needed anymore, but what harm 
>> would it do to reintroduce RTF_LLINFO? The filtering code 
>> would become a useless no-op, but you'd stay fully 
>> compatible, again both backwards and with other operating systems.
>> 
>> I just think that removing RTF_LLINFO was a bit too 
>> aggressive an optimisation with little advantage and too many 
>> disadvantages and I'd like to see it return.
> 
> I believe examining the impacts of RTF_LLINFO on the ports 
> was a good exercise even if we have to rejuvenate it.
> 
> I hope we could reach a consensus soon now that we have more 
> input from the ports developers.
> 
> Please provide your input ...

If it's easy to reintroduce it and become backwards compatible I
would do it. Like Julian said, you can give it the value 0. It
would be nice if the kernel tested for the old value as well,
perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people
upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7
keep working.