[YAMAMOTO Takashi wrote]
> - remove nqnfs support.
> 
> - make most of nfsm_ macros into functions.
>   (maybe following the style of rick's nfsv4 code.)

My current code has v2,3 (but not nqnfs, I agree it's dead and buried:-) as
well as v4 in it. The client side ports by replacing the RPC code in your
current client with calls to RPC layer routines. (These routines don't
manipulate the vfs/buffer cache, so the separation is fairly clear.) The
only macros left are build and dissect and the variables they manipulate
are in a structure.) I've ported the client to OpenBSD and Darwin8, so I
think the interfaces should be generic enough for other ports?

If you go with a port, you get v4 and kerberized nfs in the wash.

The code on ftp.cis.uoguelph.ca/pub/nfsv4 is pretty current and I can
give you some email help with the port, if you decide to go that way.

[Pavel wrote]
> nqnfs looks quite useful, but it is AFAIK broken (it crashed the kernel
> immediately last time I tried it).

Maybe, but nobody adopted it and it has essentially gone the way of the dodo.
(Once good client side caching using the delegation capability works in NFSv4
clients, I think that will be better technology. The implementations just
haven't made it there yet. Basic NFSv4 clients are out, but they either
don't have any support for delegations or minimal support, without holding
them on stable storage on the client side.)

> Yay - those nfsm_ macros are horrible to read, especially the implicit
> use of variables, most confusing.

Yep, I've taken a lot of heat w.r.t. them over the years. Finally got rid of
most of them, because I couldn't keep track of them either:-) My only
defence is that the original code was written for a 0.9MIP MicroVAXII and
avoiding function calls made a big difference on it. (At that point, the
compiler technology was still the old AT&T portable C compiler.)

Good luck with whatever you choose to do, rick