I second Max. If you are going to introduce a bunch of AF_* constants
into the tree you have to be very careful as AF_MAX is used to size
arrays and figure out how many radix trie heads to allocate.
It could be argued this wastes a bunch of CPU time and memory, though I
speculate 'not much' at the moment; I am just a bit concerned that we
have ifnet->if_afdata which is also sized based on AF_MAX, 37, even
though most of the protocols in it are never attached to ifnets.
The only domain I've seen which really uses if_afdata is PF_INET6.
PF_INET does not use it at all. In my opinion, there are structures
per-family per-ifnet which really belong hung-off ifnet on a 1:1 basis
and would simplify some of the lazy allocations we have further down in
the stack.
If AF_MAX increases significantly so will wasted memory. If you are
going to make any significant changes here, please considering moving
this stuff to a more dynamic method of allocation.
On the other hand, if you don't need to reference these constants in the
kernel at all, and they will all exist beyond AF_MAX, then you can
disregard what I've said and append them to the rest of the list.
That is pretty much what happens for the libpcap/bpf DLT constants
(which are not an exact analogue of the AF constants - we don't allocate
other, larger kernel structures based on their value).
regards,
BMS
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
