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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
