newer vnode op

[rick at snowhite.cis.uoguelph.ca]

> I am attaching a diff made against preview.  I am certain that there are
> a few problems, but it does work to some extent with nfs v3.  (v2 hasn't
> been tested yet.)

Thanks. I've just finished a first pass through nfs_vnops.c, so it shouldn't
be too long before I have something working. At that point, I'll look at
your changes.

> > I've got a client that does v2, 3 and 4, including rpcsec_gss. It's just
> > a set of rpc routines that get called by the stuff in nfs_vnops.c, instea=
> d
> > of the code that does the rpc. Currently works in OpenBSD3.8.
> 
> This is interesting; is the intention to abstract and unify the nfs rpc lay=
> er
> between the BSD's?  From my limited experience with the current
> implementation, I think it would be a welcome replacement, and v4 would
> be a nice bonus.  The nfsm_ macros alone are horrendous.

Yep, way back when I did v2 for a 0.9MIPS MicroVAXII, the macros seemed like
a good idea (a MicroVAXII used a subroutine call with lots of overhead).
Since then, they've driven me nuts, and I wrote the dang things:-)
The only macros left are build and dissect on an mbuf list. The rest are
function calls with the variables that used to be fiddled by the
macros thrown into a struct. I also separated system errors like parsing
failures from nfs error returns.

The code works in OpenBSD3.8 and the port to Dragonfly seems to have been
straightforward, sofar. (I'm currently wading through xnu-792, which has a few
surprises, but seems to be working out.)

So, I think I'll have an rpc code base that works in most bsden. Whether or
not the various bsden will adopt it, is an entirely different question. I'll
just have to wait and see on that one.

> Does your nfs code also deal direcly with mbufs?  Hopefully the abstraction
> does not incur an extra copy.

Yep, I'm still a big believer in avoiding mem<->mem copies. It's still nfs
specific. I haven't done a generic rpc system. (I heard one company, that
I think is now owned by SUN, did such a thing, but I don't think that code is
open source?)

> I have tried to keep the semantics the same, though the old lookup
> interface was a serious mess.  A few more sets of eyes, and lots of
> testing will probably be necessary.  On that note, are there any
> programs which thoroughly test nfs and the filesystem semantics?

I wouldn't say "thoroughly", but the Connectathon test suite is a good
start. (I've found that it, plus building from a fairly large source tree nfs
mounted, gets most of the problems.)

> If my work is at least somewhat similar to what Matt had in mind, I would
> be happy to try and finish it up.  As far as integrating it with your RPC
> work, it should be relatively straight forward.  The bit that needs the mos=
> t
> work is the lookup rpc abstraction.

You'd know more about that than I at this point, so it would be appreciated.
(I'm guessing 1-2 weeks before I'm ready to look at it and I'll email you
 before I do, just in case you have further changes.)

Thanks for the diffs, rick