On Fri, 12 Sep 2003, Jonathan Stone wrote:

> I dont see myself as `making an attack on kernfs'.

As I just wrote to Thor, I agree it wasn't a strong or mean attack, and I
appologize if my words didn't make that clear.

> I'm reporting, as best I recall, a consensus that was reached about
> kernfs and other subsystems: we shouldn't rely on kernfs, beacuse it
> *is* an option. Thus kernfs may not be present (for good reasons) in
> systems which, for example, want to use IPsec.

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?

Thus spdkey would run w/o kernfs, but if you had lots of keys, you really
needed kernfs as PF_KEY has issues.

If instead setkey would _not_ run, then (as I just wrote to Thor :-) I
agree with you.

> The plain fact is that using kernfs is neither necessary nor
> appropriate.

Subject to the above (that we'd still use PF_KEY w/o kernfs), I think
kernfs is a rather useful way to fix things. The kernel controls kernfs,
and the kernel knows what SPDs are around. So kernfs keeps the list of
relevant bits of info all in one place.

>               The real issue here is whether or not Itojun is making
> technical judgment calls which are appropriate for NetBSD.
> I submit that here (again, as you note with regard to performance)
> Itojun's judgemnt call was not appropriate.

As above, I assumed kernfs was an option-that-works-better-in-some-cases
type thing, so I think it's fine. :-)

> Also; if we are going to pursue fast-ipsec, then its not appropriate
> to make pre-emptive changes (like requiring kernfs access to SAs in
> userland tools) without prior consultation and consensus.

This point I actually do agree with. If KAME does kernfs policy stuff,
FAST-IPSEC should too.

Take care,

Bill