> >>Soon, though, I propose to ask the question the other way round:
> >>from a NetBSD perspective, why *not* clean up the bogosity in the
> >>current struct in6pcb? Why *not* use a hash-table for v6?  Why *not*
> >>use <sys/queue.h> for lists (&c) of in6pcbs?
> >
> >	i will fix this issue soon, however, remember it will increase my pain
> >	on kame-and-netbsd synchronization substantially.
> 
> Could I look at the the fixes first?  If you're making changes there
> already, and very minor additional changes would help migrating to
> (what I see as) a better path, then maybe we can all win.
(snip)
> If we do go with a common pcb header, very broadly like the one I
> suggested (details of course subject to discussion), then any
> NetBSD-specific changes should be restricted to just
> netinet6/in6_pcb.h and netinet/in_pcb.h.  If you are planning to add
> hash-tables to the in6pcb anway, then we could arrive at a common
> in*pcb prefix, _almost_ for free.

	ok.

> As for KAME synch issues: I dont know what is involved here.
> Could you explain a little?

	the problems i have are:
	- every single *bsd (freebsd5/bsdi4/openbsd/netbsd) use different pcb
	  structure and lookup functions!  after *bsd split, everyone got
	  innovative and made different changes all over.
	- freebsd2/bsdi3/netbsd (yes, we still support those old ones,
	  especially bsdi3 - our sponsor company is using bsdi3 and we need to)
	  needs in6pcb separate from inpcb.  however, netbsd is the
	  only one which would use hashes and CIRCLEQ.  the others (freebsd2/
	  bsdi3) use traditional 4.4BSD pcb structure, which is just like in6pcb
	  in current netbsd code.
	- kame code shares all sys/netinet6 among all operating systems.
	  therefore, if we make changes specific to netbsd (like hashes and
	  CIRCLEQ) it will result in #ifdef hell.
	- when i integrate new kame stuff into netbsd, i take diff between
	  kame sys/netinet6 and netbsd sys/netinet6, and then merge stuff by
	  hand (it is the only way i can deal with).  #ifdef hell makes it
	  very painful process.

> As for incorporating hash tables, using <sys/queue.h> macros: doesn't
> FreeBSD already do that (and also pass struct inpcb's everywhere?)
> 
> Asssuming NetBSD does get fast-ipsec to work with INET6, then FreeBSD
> may well follow suit. If that does happen, and if effort in KAME
> synching is a big issue, then just possibly you'd be better off
> overall by updating KAME's and OpenBSD's in6pcb (and sctp pcb) to match?

	with the above problem in mind, synchronizing in6pcb to freebsd/openbsd
	doesn't help at all.

itojun