RPC/XDR experience?

[Olof Johansson]

linas at austin.ibm.com wrote:

> This is exactly what is happening.

Good.

>>   if (xdrs->x_op == XDR_ENCODE
>>       && (sizeof (int32_t) == sizeof (long)
>>           || (int32_t) *lp == *lp))             //   <--  HERE is the check
>
> OK, get ready:
>
> I presume you pulled this from glibc sunrpc subdir?  Or the kernel
> rpc subdir?  (The linux kernel rpc's can/should be different than
> the glibc ones).

glibc (2.2).

> Is this a 'well known limitation'?   (i.e. that xdr_long will only
> send 32 bits), or is this a 'buggy implementation'?

This is a (well) known limitation. XDR calls 64-bit integers for "hyper integers". See RFC1014 for
reference.

> If its 'well known', where is it documented? 'man xdr' gives no hint,
> and implies the opposite is true  ...

I can't find any documentation on Linux/glibc for this. This is the behaviour that AIX, Solaris and
other ONC+-based implementations have, to change it would be a bad idea for compatibility reasons.

http://docs.sun.com/db/doc/806-6543/6jffrdmf8?a=view for reference. Search for "xdr_long":

"The XDR routine xdr_long(3NSL) might seem to be a problem; however, it is still handled as a 32-bit
quantity over the wire to be compatible with existing protocols. If the 64-bit version of the
routine is asked to encode a long value that does not fit into a 32-bit quantity, the encode
operation fails."

> Does RPC define a 64-bit encoding (that can be received by 32-bit
> servers)?

xdr_hyper()

> If so, shouldn't the xdr_long be modified to use the 64-bit marshalling?

It would probably not be wise, since there's a lot of 32-bit code out there that will change
protocol behavior if it's recompiled in 64-bit mode, etc.

> I'm thinking to myself that there are valid reasons for applications
> on 32-bit CPU's to use 64-bit ints.  I know gcc handles 64-bit 'long-long
> ints' on intel machines just fine, and has done so for at least 5 years.
> (if not 10).  By extension, one must conclude that there are valid
> reasons for RPC's to support 64-bit ints, even on 32-bit arch's.
> If you buy the argument in the last 3 sentances, then I would think
> that xdr_long should be generating a 64-bit wire protocol on ppc64.
>
> There. Pandora's box is now open ...

Nah, no need to make the problem bigger than it already is and fix something that isn't broken.


-Olof

--
Olof Johansson                                        Office: 4E002/905
pSeries Linux Development                             IBM Systems Group
Email: olof at austin.ibm.com                          Phone: 512-838-9858
All opinions are my own and not those of IBM


** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/