In message <20030824212553.3B07A91@coconut.itojun.org>,
itojun@iijlab.net writes:


>>If the lower-layer (here, IPsec) needs to have state in common across
>>different higher-level protocols, then its *better* to make that state
>>actually be shared.
>
>	this point we can't seem to find an agreement.


Maybe so.  Where I come from, such examples are a staple ingredient of
programming-language courses. Perhaps I am brainwashed, but both the
courses and experience left me (strongly) opposed to burying switches
on object-type, deeply nested two or three levels of abstraction below
the object being swicthed on.

IME, it is almost invariably a nightmare for documentation, ease of
maintenance, and eventual clarity and quality of code -- all things
which are important to the NetBSD project.

Though, perhaps we will just have to agree to disagree.

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

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

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.

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?