[...]
>	ok.

Many, many thanks.


>> 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 in6pc
>b
>	  in current netbsd code.

I have not looked closely at FreeBSD 5. FreeBSD 4.4 to 4.8 has an
inpcb with two LIST_ENTRY() fields (not circleqs). I see now the
struct-member names are different (FreeBSD 4.x has a LIST_ENTRY()
called inp_list, where we have a CIRCELQ_entry called inp_queue.

``Yuck.''  Thanks, thats a much clearer picture of your headache.

I assume you've already looked into scripts to automatically construct
in6_pcb.h from a per-OS template.  Or tried a shim-layer to isolate
the KAME ipv6 code from more of the surrounding OS (hash-tables, etc)?

Tho given the cumulative rate of trash over 3 or 4 *BSD trees, you
might never recoup the time invested. Or even catch up: a red queen's
race[*].


>	- 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.

Yikes! But on the other hand, not having a hash-table and resorting to
a linear scan on each and every pcb lookup, means that KAME v6 is (no
slur intended, here) rather a bit of toy-system?  At least by
contemporary standards: one could not really deploy any IPv6 without
hashtables in the heavy-duty environments where *BSD IP/TCP is
currently deployed with hundreds or thousands of simultaneous [ipv4]
connections, at least unless you are willing to acecpt lower
performance levels.  Is that a fair comment?

NB, I'm not complaining: I'm just asking. It does seem a clear
conseqence of comments you've made here, both recently and over the
past few years, consequences which had not really sunk in yet (at
least not for me, assuming too that my inference is valid.).


I shouldn't teach you to suck eggs[**], and its not my bed to lie on
anyway.  But if it were me, I would think hard about a per-target-os
header file with a per-target-os source file, so that you could deal
with (e.g.)  in6pcb hash-table lookups once per target OS, instead of
patching pcb-hash diffs from a single unified KAME tree, on each and
every merge, for each and every target OS. As above, one would have to
choose very judiciously what to put in the per-OS files, and what to
deal with manually.


>	- 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.



[*]  Lewis Carroll, Alice in Wonderland/Through the Looking Glass.
     the red queen has to run all the time, just to keep up wiwth
     where she is.

[**] ``teaching your grandmother to suck eggs'' == dated colloqualism
     for explaining something to someone who's know it longer than
     the explainer (or possilby longer than the explainer has been alive).
     c.f. Tolkien's ``The Hobbit'', where in his youth, Gollum
     would teach his grandmother to suck eggs.