Re: HEADSUP: arp-v2 has been committed

From: Tijl Coosemans <tijl_at_ulyssis.org>
Date: Sat, 27 Dec 2008 14:58:50 +0100
On Saturday 27 December 2008 13:28:42 Gerald Pfeifer wrote:
> On Tue, 23 Dec 2008, Tijl Coosemans wrote:
>>> No, the output of this command is still the same. NET_RT_DUMP
>>> obtains the entire L3 table and filtering for RTF_GATEWAY
>>> non-multicast routes have the same semantics. Those flags never
>>> apply to L2 entries.
>> 
>> Thanks for answering my questions. I've attached the patch for Wine.
> 
> Thanks, Tijl!  Are you also going to submit this patch upstream or
> would you prefer me to submit my (syntactically different, but
> equivalent) version?  I'd love to see this addressed in Wine 1.1.12.

I was kind of waiting for the dust to settle.

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. 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.

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.
Received on Sat Dec 27 2008 - 12:58:56 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC