From owner-freebsd-net@FreeBSD.ORG Sat Dec 27 23:07:28 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 CC7721065673; Sat, 27 Dec 2008 23:07:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id A4DAA8FC19; Sat, 27 Dec 2008 23:07:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBRN7RwG091538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Dec 2008 15:07:27 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <4956B52F.2070300@freebsd.org> Date: Sat, 27 Dec 2008 15:07:27 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Julian Elischer References: <20081227204756.B58938FC1F@mx1.freebsd.org> <4956B22A.6080109@elischer.org> In-Reply-To: <4956B22A.6080109@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Qing Li , freebsd-net@freebsd.org, 'Gerald Pfeifer' , freebsd-current@freebsd.org, 'Tijl Coosemans' 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: Sat, 27 Dec 2008 23:07:28 -0000 Julian Elischer wrote: > Qing Li wrote: >> >> >> 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 ... > > reintroduce it with value 0 > then teh optimiser should remove dead code... > The worry is that this will cause subtle bugs when code assumes functionality is present. We tried yanking this entirely and it's obviously caused some issues. The question now is whether to follow through and accept an incompatibility or put back sufficient compatibility to enable legacy code to work unchanged. Sam