From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 14:46:56 2007 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2886A16A418; Mon, 3 Sep 2007 14:46:56 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id C775313C459; Mon, 3 Sep 2007 14:46:55 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 21BE91D3D7; Mon, 3 Sep 2007 10:46:43 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 03 Sep 2007 10:46:43 -0400 X-Sasl-enc: cQ6O1MIP3xpaH8SaZOWRX8B6KyNRBSJVLKglU8Id8WoG 1188830802 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 8E203187DA; Mon, 3 Sep 2007 10:46:42 -0400 (EDT) Message-ID: <46DC1E51.3040707@FreeBSD.org> Date: Mon, 03 Sep 2007 15:46:41 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.4 (X11/20070630) MIME-Version: 1.0 To: Alfred Perlstein References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> In-Reply-To: <20070902211945.GQ87451@elvis.mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , net@freebsd.org Subject: Re: Allocating AF constants for vendors. 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: Mon, 03 Sep 2007 14:46:56 -0000 Alfred Perlstein wrote: > Ok, I'm not really sure what to do here. At Juniper we have approx > 20 additional entries for AF_ constants. We also have theoretical > but not practical "problems" with spareness and utility of this > list, meaning we have plenty of arrays in our version of ifnets and > route entries that are also "bloated" as well. > Can you merge them into the list in such a way that AF_MAX does not need to slide forward? Or do they need to be referenced from within the kernel tree itself? Prevention of code bloat is better than the cure. Not having the code in front of me I couldn't say for sure if we're talking about a dozen bytes or several pages potentially being wasted, so it is impossible to judge. One of my concerns is that we have ifnet.if_afdata, we're not really using it, it makes sense to use it for some things. Help from big companies as well as little folks is always appreciated, providing we can reach consensus. > Otherwise one other policy would be to specify an allocation > policy such that new AF_ constants are allocated only for even > numbers where odd numbers are left to vendors. > > This would slow the "bloat" and still provide vendors with something > useful. > > How does that sound? > EPARSE? I don't follow this at all. BMS