From owner-freebsd-net@FreeBSD.ORG Sun Dec 28 15:13:52 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9745106564A; Sun, 28 Dec 2008 15:13:52 +0000 (UTC) (envelope-from tijl@ulyssis.org) Received: from mailrelay002.isp.belgacom.be (mailrelay002.isp.belgacom.be [195.238.6.175]) by mx1.freebsd.org (Postfix) with ESMTP id ECABB8FC08; Sun, 28 Dec 2008 15:13:51 +0000 (UTC) (envelope-from tijl@ulyssis.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAFslV0lXQHIo/2dsb2JhbACBbLsNWI5xhkQ Received: from 40.114-64-87.adsl-dyn.isp.belgacom.be (HELO kalimero.kotnet.org) ([87.64.114.40]) by relay.skynet.be with ESMTP; 28 Dec 2008 16:13:50 +0100 Received: from kalimero.kotnet.org (kalimero.kotnet.org [127.0.0.1]) by kalimero.kotnet.org (8.14.3/8.14.3) with ESMTP id mBSFDnr1003012; Sun, 28 Dec 2008 16:13:49 +0100 (CET) (envelope-from tijl@ulyssis.org) From: Tijl Coosemans To: "Qing Li" Date: Sun, 28 Dec 2008 16:13:47 +0100 User-Agent: KMail/1.9.10 References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> In-Reply-To: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812281613.49404.tijl@ulyssis.org> Cc: 'Qing Li' , freebsd-net@freebsd.org, Gerald Pfeifer , freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Dec 2008 15:13:52 -0000 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.