Date: Tue, 4 Sep 2007 13:54:54 -0700 From: Alfred Perlstein <alfred@freebsd.org> To: Randall Stewart <rrs@cisco.com> Cc: Max Laier <max@love2party.net>, "Bruce M. Simpson" <bms@freebsd.org>, net@freebsd.org Subject: Re: Allocating AF constants for vendors. Message-ID: <20070904205454.GY87451@elvis.mu.org> In-Reply-To: <46DDB9E9.4010408@cisco.com> References: <20070821232956.GT87451@elvis.mu.org> <46CC45F0.3000105@FreeBSD.org> <20070902211945.GQ87451@elvis.mu.org> <46DC1E51.3040707@FreeBSD.org> <20070903201133.GU87451@elvis.mu.org> <46DD2F3A.20904@FreeBSD.org> <20070904124224.GF87451@elvis.mu.org> <46DDB9E9.4010408@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Randall Stewart <rrs@cisco.com> [070904 13:22] wrote: > Alfred Perlstein wrote: > >* Bruce M. Simpson <bms@FreeBSD.org> [070904 03:08] wrote: > > > >>>As you can see we are defering the "bloat". > >>>Does that make sense? > >>> > >> > >>I follow but it still doesn't really make sense. > >> > >>Granted, you are deferring the growth of arrays sized off AF_MAX but > >>only ever by 1 slot. > >>What if Vendor Z wants to add 25 entries at once? > > > > > >Then as long as they allocate odd numbered entries they should > >be fine. FreeBSD's AF_MAX does not need to change to accomidate > >a vendor, it only has to restrict itself to even numbered slots. > > > > > >>We would also be tying ourselves down to the notion of a vendor in any > >>AF_ allocation. Is this an avenue that people are happy to pursue? > > > > > >Yes, until the "horrific" problem of the statically sized arrays > >is "fixed". Then the allocation policy can change. > > > > > So basically in this scheme we only have to "stumble" across an > additional slot when we add a new one to FreeBSD.. i.e. some > random vendor may assign 50 slots (in odd numbers) but FreeBSD > would not see the growth until really 2 new AF_XXX's are added. > Then you would have to bump it from by 3, to cover the two > new ones (reserving the vendor specific slots and thus causing > allocations of unused things). YES! Exactly. > > This seems like a reasonable compromise to me... I can't imagine > where we would need to add a lont of new AF_XXX's.. of course > maybe I just lack imagination :-D Well, Freebsd or 5 added bluetooth, and freebsd 7 has some IEEE thing added... sooo... the array is growing, but slowly. -- - Alfred Perlstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070904205454.GY87451>