HEADSUP: arp-v2 has been committed
Qing Li
qingli at speakeasy.net
Sat Dec 27 20:21:15 UTC 2008
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 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?) ?
>
> 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 ?
>
> 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 ...
-- Qing
More information about the freebsd-current
mailing list