Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: Jun-ichiro itojun Hagino <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/11/2003 18:08:45
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.