Allocating AF constants for vendors.

[Randall Stewart]

Alfred Perlstein wrote:
> * Bruce M. Simpson <bms at 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).

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

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)