Allocating AF constants for vendors.
alfred at freebsd.org
Tue Sep 4 13:57:49 PDT 2007
* 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).
> 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
More information about the freebsd-net