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