>I haven't seen the code; if you can point me at it, I can offer a more
>informed opinion.  But I have trouble believing that it's all that
>difficult to use curproc->p_pptr instead of curproc.  (Actually, I
>think that if it is, the code is in severe need of a rewrite anyway,
>but that's neither here nor there for the immediate point.)

Fair enough; the whole AFS implementation is at http://www.openafs.org;
the kernel cache manager implementation is in the "afs" directory of
the source tree.

>I don't agree that setting an environment variable is "teaching the
>upper layer about each authentication system"; setting an environment
>variable is a sufficiently generic and common thing that it's
>reasonable to put a facility for it into the protocol.  (Indeed, one
>could argue it would be unresaonable not to.)  Making custom syscalls
>isn't, which is why I didn't mention that for AFS - but if you have
>custom syscalls, I see no reason why they can't affect whichever
>process you want them to.

Again, it boils down to real world issues ... I'm saying that rather
than hack on AFS for a NetBSD-specific hack, I'd rather spend my time
writing PAM modules, since I have a chance of that work being reusable.
Yes, PAM doesn't exist for NetBSD, yes ... I'm saying what I would do
if it _does_.  And yes, I don't _need_ PAM ... I can install a custom
login program (which I what I do now), or integrate it into the provided
login program.  But, again ... time isn't infinite.  The more time I can
spend on a reusable solution, the better.

--Ken