Allocating AF constants for vendors.

[Alfred Perlstein]

* Randall Stewart <rrs at cisco.com> [070904 13:22] wrote:
> 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).

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