>> I understand that policy, and I respect it. Usually, I follow it also.
>> 
>> But we're talking about part of the kernel that has a huge impact on
>> network throughput. It really needs to be lean and mean. While what you're
>> describing is fine for IA-32 and moderately-heavy loads, if we push the
>> envelope, either with lots of connections or with lighter (embedded)
>> hardware, we'll be hurting ourselves.
>> 
>> What parts along the so->so_proto->pr_domain->dom_family chain will change
>> during a socket's lifetime? I think the best thing to do is comment "If
>> you change this, you need to change the in{,6}pcb."
>
>	ok, i understand.  if there's no problem in breaking kmem grovellers
>	i can introduce "int inp_af" field to inpcb (location aligned with
>	in6pcb) and use it to distinguish the two.  i also can make inpcbtable
>	unified (instead of inpcbtable/in6pcbtable) but i'm not sure how
>	good hash distribution will be.

	ftp.itojun.org:~ftp/pub/netbsd-20030826b-inet6hash.diff.gz

itojun