Date: Mon, 3 Sep 2007 13:11:33 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: Max Laier <max@love2party.net>, net@freebsd.org Subject: Re: Allocating AF constants for vendors. Message-ID: <20070903201133.GU87451@elvis.mu.org> In-Reply-To: <46DC1E51.3040707@FreeBSD.org> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Bruce M. Simpson <bms@FreeBSD.org> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070903201133.GU87451>