Date: Mon, 2 Aug 1999 07:32:08 -0400 (EDT) From: Alfred Perlstein <bright@rush.net> To: hackers@FreeBSD.ORG Subject: Re: confusion about nfsm_srvmtofh bad behavior? Message-ID: <Pine.BSF.3.96.990802072500.20420l-100000@cygnus.rush.net> In-Reply-To: <Pine.BSF.3.96.990802064748.20420k-100000@cygnus.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2 Aug 1999, Alfred Perlstein wrote:
> } \
> if (fhlen != 0) { \
> nfsm_dissect(tl, u_int32_t *, NFSX_V3FH); \
> bcopy((caddr_t)tl, (caddr_t)(f), NFSX_V3FH); \
> if ((nfsd->nd_flag & ND_NFSV3) == 0) \
> nfsm_adv(NFSX_V2FH - NFSX_V3FH); \
> } \
> }
...
> it then rewinds the mbuf pointers (i think) because of the
> over "dissection" above.
> ---
>
> why does it do the copy, then rewind it, it seems like it knows
> it's doing something wrong and instead of fixing it, it just
> compensates after the fact.
yes, replying to my own message.
the only thing i can think of is that the extra data is safely
ignored because the routines that use these macros seem to
pass the version of NFS to all the function that they call...
however unless i'm wrong (which i probably am) nfsV2 stuff
could be made faster if it was correctly noted and less data
was copied. It would also DTRT and not access data it isn't
supposed to :)
it seems like all of the V3 handles are the same length so
there isn't much to do there...
-Alfred
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990802072500.20420l-100000>