>> 	the pointer dereference is really a concern, you can keep so-to-family
>> 	mapping table cache.
>
>Ok. Why not just include said cache in the in{,6}pcb? Having multiple
>caches doing the same thing doesn't seem like a good idea. Assuming I'm
>understanding your suggestion right.

	my instinct (or usual rule) says that it is bad to hold the same
	information in multiple locations, as it is easy to for those to go
	inconsistent and have bad sideeffects, so i prefer to reference
	so->so_proto->pr_domain->dom_family for address family.

	and no, "so-to-family mapping table cache" is not my favorite idea.
	it is just a counter example to your previous comment.

>Careful, yes. But stagnant, no. If the change is really useful (and
>getting rid of so->so_proto->pr_domain->dom_family and cleaning things up
>sounds like it is), then we should make the change.
>
>We also have pkgsrc, where we can fix things, so that our users don't end
>up hosed. And to be honest, we have changed a number of other structures
>that have had (AFAICT) comparable impact on kvm-grovelers.

	fyi: the diff i've posted yesterday does not change inpcb.

itojun