On Tue, 3 Aug 1999, Peter Wemm wrote:
> Alfred Perlstein wrote:
> > On Mon, 2 Aug 1999, Matthew Dillon wrote:
> >
> > http://big.endian.org/~bright/freebsd/patches/nfsm_subs.diff
> >
> > This is a patch that Peter Wemm proposed however he had this:
> >
> > ! if (fhlen < NFSX_V3FH) { \
> > ! bzero((caddr_t)(f) + fhlen, NFSX_V3FH - fhlen); \
> > ! } \
> >
> > right before the while(0) instead of the else clause with the
> > full bzero.
> >
> > i'd rather get rid of the extra copying going on and since
> > previously it was filled with garbage from the rest of the RPC
> > structure i don't think it's nessesary.
>
> Right now it seems we're generating 8 bytes of fsid and 12 (padded to 16)
> bytes of handle data in the common case for a total of 24 bytes of filehandle.
> Then we pad that to 32 bytes for V2 or 64 bytes for V3, with random crud.
> Then we copy this around, store it all in memory, transmit it over the wire,
> etc. It's a nightmare.
yes, ick! :)
> NFSv2 filehandles are fixed at 32 bytes long. For V3 we could probably just
> transmit 24 byte filehandles rather than 64. (I'll reread the spec to make
> sure there isn't a v3 minimum size).
there isn't, the only reason i can think of forcing it to the full
64 bytes is that it may interact badly with other NFS implementations
that may not handle it correctly.
>
> That explicit zero on the end is probably redundant since we've been using
> random data in it's place since day 1. (We do need (I think) the fhlen ==
> 0 bzero though).
It should probably error and do the same thing that happens above,
however, i'm too tired to determine if it's safe to do that after
the second nfsm_dissect(), and since it's an error condition that
would only happen with a corrupted packet or somesuch it can
probably be left alone.
I appreciate the time you've taken on IRC to enlighten me about
these things.
thank you,
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
