From owner-freebsd-hackers  Mon Aug  2  4:16:47 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133])
	by hub.freebsd.org (Postfix) with ESMTP id 2654F15290
	for <hackers@freebsd.org>; Mon,  2 Aug 1999 04:16:40 -0700 (PDT)
	(envelope-from bright@rush.net)
Received: from localhost (bright@localhost)
	by cygnus.rush.net (8.9.3/8.9.3) with SMTP id HAA02295
	for <hackers@freebsd.org>; Mon, 2 Aug 1999 07:18:37 -0400 (EDT)
Date: Mon, 2 Aug 1999 07:18:36 -0400 (EDT)
From: Alfred Perlstein <bright@rush.net>
To: hackers@freebsd.org
Subject: confusion about nfsm_srvmtofh bad behavior?
Message-ID: <Pine.BSF.3.96.990802064748.20420k-100000@cygnus.rush.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


ok:

#define nfsm_srvmtofh(f) \
	{ int fhlen = NFSX_V3FH; \
		if (nfsd->nd_flag & ND_NFSV3) { \
			nfsm_dissect(tl, u_int32_t *, NFSX_UNSIGNED); \
			fhlen = fxdr_unsigned(int, *tl); \
			if (fhlen == 0) { \
				bzero((caddr_t)(f), NFSX_V3FH); \
			} else if (fhlen != NFSX_V3FH) { \
				error = EBADRPC; \
				nfsm_reply(0); \
			} \
		} \
		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); \
		} \
	}

notice the bcopy?  i don't really understand why we always
seem to copy 64 bytes (NFSX_V3FH), isn't this a bug?

NFSX_V3FH is 64 right?

my understanding of the code is as follows:

---
fhlen set to 64,

if we are using NFS3, extract the size of the handle from the mbufs
  if it's not valid abort with an error

now advance to the data portion (the filehandle)

copy it into the file handle, but copy 64 bytes regardless
  of the value of 'fhlen', in fact if we are using NFSv2 then
  it should only copy 32 bytes no?

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.

<amused rant>
it would have been nice if some of the variables used here
were more than 3 charaters and there was a comment or two
sprinkled about.

the code is actually pretty nifty and makes sense, but you need
to stare at it for a few hours before you can make heads or
tails of anything.  the fact that nested macros used modify
variables in the calling function is really, urm... cool? :)
</rant>

-Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] 
systems administrator and programmer
    Wintelcom - http://www.wintelcom.net/



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message