Date: Sat, 27 Dec 2008 12:21:25 -0800 From: "Qing Li" <qingli@speakeasy.net> To: "'Tijl Coosemans'" <tijl@ulyssis.org>, "'Gerald Pfeifer'" <gerald@pfeifer.com> Cc: 'Qing Li' <qingli@freebsd.org>, freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: RE: HEADSUP: arp-v2 has been committed Message-ID: <20081227202115.B26AF8FC12@mx1.freebsd.org> In-Reply-To: <200812271458.52492.tijl@ulyssis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081227202115.B26AF8FC12>