In message <20030911234732.7DD3E8A@coconut.itojun.org>Jun-ichiro itojun Hagino writes
>> Anyway ...  if we go down that route, then during the transition
>> period, changes to the PF_KEY API have to be synchronized across both
>> IPsec implementations.  Ad-hoc changes to the PF_KEY api (or abi) in
>> one will likely break the other.
>
>	i remember no ad-hoc changes to PF_KEY API/ABI made to netbsd tree.
>	which one do you think ad-hoc?
>	i made changes with reasons.  if you call it "ad-hoc" in public it's
>	quite a insult.

There is a bug in the implementation PF_KEY which is triggered with
quite modest numbers of simultaneous SAs.  Addding a kernfs hook to
access SAs in order to sidestep that bug is *definitionally*, ad-hoc.

Please bear keep in mind the long-established NetBSD principle that
kernfs is *optional*: subsystems should continue to work even if
kernfs is not present. You can use kernfs as an optimization, if its
present; but as I recall the consensus, we should never **equire* it.
(Perhaps I am misremembering, or perhaps this predates your involvement with NetBSD?)

Also please remember the NetBSD principle: "no code before its time".
We should not check in ad-hoc kludges in response to bugs.  So, with
all due respect, please do not commit ad-hoc kludges like this in
future.  Instead, please *fix the bug*.

I'm not 100% sure its the same bug which manifests on fast-ipsec (both
NetBSD and FreeBSD) under the same circumstances of medium numbers of
SAs; but the description sure sounds very similar.

I have been trying (and failing) to build a -current kernel for my
laptop that doens't panic immediately for almost a week now. Once I
get one built, I'd be glad to check whether this is the saem bug, and
to collaborate on a real fix.