From owner-freebsd-current@FreeBSD.ORG Sat Dec 27 20:21:15 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D8D1065674 for ; Sat, 27 Dec 2008 20:21:15 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.6]) by mx1.freebsd.org (Postfix) with ESMTP id B26AF8FC12 for ; Sat, 27 Dec 2008 20:21:15 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: (qmail 12277 invoked from network); 27 Dec 2008 20:21:15 -0000 Received: from dsl081-051-194.sfo1.dsl.speakeasy.net (HELO qm8nwm5acsx) ([64.81.51.194]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 27 Dec 2008 20:21:15 -0000 From: "Qing Li" To: "'Tijl Coosemans'" , "'Gerald Pfeifer'" Date: Sat, 27 Dec 2008 12:21:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200812271458.52492.tijl@ulyssis.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcloK0Nf0n7CsmqYRgyE2M14UKtkGQAL8eAg Message-Id: <20081227202115.B26AF8FC12@mx1.freebsd.org> X-Mailman-Approved-At: Sat, 27 Dec 2008 21:19:17 +0000 Cc: 'Qing Li' , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: RE: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Dec 2008 20:21:15 -0000 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