In message <20030912010102.3138A8A@coconut.itojun.org>Jun-ichiro itojun Hagino writes
[...]

>> So if it's identical, you would accept demonstrationn of a bug against
>> the sys/netipsec code as applicable to the KAME sys/netkey tree?
>> 
>> If so,, the bug can be demonstrated quite easily[*].  With
>> approximately 340 SAs total, setkey starts returning EAGAIN.
>
>	nowhere in sys/netkey we return EAGAIN.  therefore it's not my problem.

That is far from clear. If I knew how to fix the problem -- why the
PF_KEY code was triggering EAGAIN, or why racoon sleeps forever in
sbwait() -- then I'd fix it. Maybe the problem by which you justified
the kernfs is a sepearate problem. It is, however, clearly the pf_key
socket which is incurring the EAGAIN and the sbwait().


>	if you still flame me, prove where is the source of EAGAIN.


Itojun, what are you talking about?  I have not been flaming *you*.
I've made an description of certain *CVS commits* as being ad-hoc,
given the accepted practive for NetBSD. A key part of that "ad-hoc"
description is that we have a long-established consensus *not* to rely
on kernfs in such cases (as I have said, several times, now.)

I dont see how that constitutes flaming you, personally.
In fact, I have tried to keep personalities out of the discussion.