From owner-freebsd-net@FreeBSD.ORG Mon Sep 3 20:14:25 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 14FFD16A41A; Mon, 3 Sep 2007 20:14:25 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id EEA7113C428; Mon, 3 Sep 2007 20:14:24 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E0EBC1A4D9A; Mon, 3 Sep 2007 13:11:33 -0700 (PDT) Date: Mon, 3 Sep 2007 13:11:33 -0700 From: Alfred Perlstein To: "Bruce M. Simpson" Message-ID: <20070903201133.GU87451@elvis.mu.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46DC1E51.3040707@FreeBSD.org> User-Agent: Mutt/1.4.2.3i 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 20:14:25 -0000 * Bruce M. Simpson [070903 07:44] wrote: > 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? They are refenced inside the kernel. > 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. Well, for the most part it's going to be something like 32*sizeof(void*) so 128 or 256 bytes depending on arch. > 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. I'll have ot look into this. > Help from big companies as well as little folks is always appreciated, > providing we can reach consensus. YES! :) > >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. Ok, let's say we garantee that going forward, all odd AF_ constants are verdor reserved.... So whenever FreeBSD allocates an AF constant, it should be even, vendors can use odd. That means that, from socket.h: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_MAX 38 Now let's say FreeBSD wants to add a AF constant, the next one to allocate would be 38, so we have: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_MAX 39 Ok, well that doesn't explain it much, however, shortly thereafter we allocate another AF constant in FreeBSD, the list now looks like: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_VENDOR0 39 /* reserved for vendors. */ #define AF_NEWPROTO2 40 /* some awesome new protocol! */ #define AF_MAX 41 Soon another protocol is added: #define AF_ARP 35 #define AF_BLUETOOTH 36 /* Bluetooth sockets */ #define AF_IEEE80211 37 /* IEEE 802.11 protocol */ #define AF_NEWPROTO1 38 /* some awesome new protocol! */ #define AF_VENDOR0 39 /* reserved for vendors. */ #define AF_NEWPROTO2 40 /* some awesome new protocol! */ #define AF_VENDOR1 41 /* reserved for vendors. */ #define AF_NEWPROTO3 42 /* some awesome new protocol! */ #define AF_MAX 43 As you can see we are defering the "bloat". Does that make sense? -- - Alfred Perlstein