I applied the nfs_all patch from
http://www.fys.uio.no/~trondmy/src/2.4.19/ to a linux-2.4.19 kernel, and
ran into trouble compiling.
In particular, the linux-2.4.19-02-fix_kmap2.dif patch defines a
conflicting type for xdr_shift_buf's second argument. In
linux-2.4.19/include/linux/sunrpc/xdr.h, it is defined to be of type
unsigned int, and in linux-2.4.19/net/sunrpc/xdr.c, it is defined to be
of type size_t.
Size_t is defined to be __kernel_size_t in /usr/include/linux/types.h,
which is defined to be unsigned long in /usr/include/asm/posix_types.h.
On an IA32 architecture, unsigned long and unsigned int are the same, so
this is not a big deal. However, on an alpha, a long is 64 bits,
whereas an int is only 32 bits.
Should xdr_shift_buf take an int or a long? Are there any other known
problems for a 64-bit architecture in the nfs_all patches?
Thank you,
dbr
--
David B. Ritch
High Performance Technologies, Inc.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
>>>>> " " == David B Ritch <[email protected]> writes:
> Should xdr_shift_buf take an int or a long? Are there any
It should indeed take a size_t as is done in 2.5.x, and
2.4.20-pre5. Sorry I forgot to apply that change to my own tree.
> other known problems for a 64-bit architecture in the nfs_all
> patches?
Not that I'm aware of.
Cheers,
Trond
diff -Nru a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
--- a/include/linux/sunrpc/xdr.h Wed Sep 4 00:58:53 2002
+++ b/include/linux/sunrpc/xdr.h Wed Sep 4 00:58:53 2002
@@ -138,7 +138,7 @@
*/
extern int xdr_kmap(struct iovec *, struct xdr_buf *, unsigned int);
extern void xdr_kunmap(struct xdr_buf *, unsigned int);
-extern void xdr_shift_buf(struct xdr_buf *, unsigned int);
+extern void xdr_shift_buf(struct xdr_buf *, size_t);
extern void xdr_zero_buf(struct xdr_buf *, unsigned int);
/*
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Thank you. That seems to have taken care of it.
David
On Tue, 2002-09-03 at 18:59, Trond Myklebust wrote:
> >>>>> " " == David B Ritch <[email protected]> writes:
>
> > Should xdr_shift_buf take an int or a long? Are there any
>
> It should indeed take a size_t as is done in 2.5.x, and
> 2.4.20-pre5. Sorry I forgot to apply that change to my own tree.
>
> > other known problems for a 64-bit architecture in the nfs_all
> > patches?
>
> Not that I'm aware of.
>
> Cheers,
> Trond
>
> diff -Nru a/include/linux/sunrpc/xdr.h b/include/linux/sunrpc/xdr.h
> --- a/include/linux/sunrpc/xdr.h Wed Sep 4 00:58:53 2002
> +++ b/include/linux/sunrpc/xdr.h Wed Sep 4 00:58:53 2002
> @@ -138,7 +138,7 @@
> */
> extern int xdr_kmap(struct iovec *, struct xdr_buf *, unsigned int);
> extern void xdr_kunmap(struct xdr_buf *, unsigned int);
> -extern void xdr_shift_buf(struct xdr_buf *, unsigned int);
> +extern void xdr_shift_buf(struct xdr_buf *, size_t);
> extern void xdr_zero_buf(struct xdr_buf *, unsigned int);
>
> /*
--
David B. Ritch
High Performance Technologies, Inc.
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs