Subject: Re: Reminder that we are supporting two parallel IPsec implementations
To: Bill Studenmund <firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 09/12/2003 17:42:28
On Fri, Sep 12, 2003 at 02:35:13PM -0700, Bill Studenmund wrote:
> On Fri, 12 Sep 2003, Jason Thorpe wrote:
> > On Friday, September 12, 2003, at 01:28 PM, Bill Studenmund wrote:
> > > Ok, maybe I'm on the wrong page. I assumed that Itojun _added_ kernfs
> > > supoprt, and that if kernfs wasn't there, we'd use PF_KEY instead. Is
> > > that
> > > assumption correct or incorrect?
> > That is correct. However, the PF_KEY interface was a second-class
> > citizen to the kernfs interface, since the PF_KEY interface has a
> > restriction that the kernfs interface does not have.
> > That means that kernfs WOULD BE REQUIRED to support large numbers of
> > IPsec SAs.
> So? You're saying that kernfs does somethign well, and is the best choice
> in certain circumstances? So why not use it? If that means it's what's
No, what he's saying is that the current PF_KEY code is *broken*, and
that the "fix" for it is to require the use of a nonstandard interface
instead of the standard one any time there's a possibility that enough
SAs might be returned. I don't care if the nonstandard interface is
kernfs or a jelly donut, that's just plain wrong. If you want to go
on a crusade about how kernfs is good and we should use it, be my guest;
just don't conflate it with the issue of whether our PF_KEY should be
broken unless some nonstandard extension is used, which is a fundamental
code quality and portability issue that's entirely separate from the issue
of whether kernfs should be required.