> The simple fact is that the very existence of the kernfs API to [...]

I think I'm beginning to see part of the problem.

You are seeing kernfs as an API.  I see kernfs primarily as a human
interface.  While I haven't looked at it in enough detail to be sure, I
suspect that I would agree that PF_KEY is a better *API*.  But it means
special-purpose tools need to exist for humans to, for example, figure
out why something isn't working, rather than poking around with cat and
echo with kernfs.

I've used interfaces of both styles.  I've even designed and built
interfaces of both styles.  That's why I like to have them both
available, because they're good for different things.

> [...]  Just compare the kernel hooks required for kernfs with the
> corresponding sysctl interface.

Finally, some light.

Yes, if the kernfs interface significantly impairs (uglifies,
complicates, whatever) the rest of the code, that can be a good reason
for preventing, or eliminating, it.  (Its origins, which you went into
such length about, I see as mostly irrelevant: just because something
is the wrong fix for problem A doesn't mean it can't be useful for
purpose B anyway.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B