Add XDR support (only built #if cygwin, for now)

[Eric Norum]

I did the original port of the Sun (FreeBSD) RPC/XDR code to RTEMS.  The heavy modifications that Ralf referred to were to make the RPC code reentrant.  As the README_RTEMS below says, there were no changes to the XDR code.  I agree that for now we should stick with the RTEMS versions, but in the longer term it would be great to have solid, thread-safe, reentrant XDR and RPC routines in newlib.  Code that someone else develops and maintains is always a good thing.

The RTEMS version of the code is in the RTEMS distribution under cpukit/librpc/.  Here's the README_RTEMS from that directory:
USING RPC/XDR ON RTEMS
======================
For the most part, programmers using RPC/XDR routines on RTEMS
can proceed as if they were to be using a POSIX/UNIX system.
The only significant changes are those to start the portmapper
and to allow use of RPC/XDR by multiple threads.

Starting the portmapper
=======================
The SUN portmapper program has been modified to run as an RTEMS
task.  Applications which need the portmapper can start this
task by calling:
	int rtems_rpc_start_portmapper (int priority);
The return value is an RTEMS status code.

Multi-threaded operation
========================
The RPC/XDR package has been modified to allow for multiple RTEMS
tasks to use RPC/XDR routines.  If more than one task is to call
an RPC/XDR routine, the additional tasks must call:
	int rtems_rpc_task_init(void);
before calling any RPC/XDR routines.  For example, the portmapper
calls this routine since the portmapper uses RPC/XDR routines in
a separate thread.
The return value is an RTEMS status code.


Porting Notes
=============
Most of the FreeBSD rpc library ports to RTEMS with little
or no modification beyond that required to provide for operation
in a multitasking environment.  Multitasking operation was
provided by moving all `static persistence' variables into
a single structure and using an RTEMS task variable to point
to that structure.  

Some of the library, however, has not made it into the RTEMS
implementation.  FreeBSD source files which have been left out include:
- Files which provide RPC to the AF_UNIX address family:
	clnt_unix.c
	svc_unix.c
  An `ifndef __rtems__' was added to clnt_generic.c because clnt_unix.c
  was omitted.
- Files which need NIS:
	auth_time.c
- Files which provide DES authentication:
	auth_des.c
	authdes_prot.c
	crypt_client.c
	des_crypt.c
	des_soft.c
	getpublickey.c
	key_call.c
	key_prot_xdr.c
	svc_auth_des.c

The FreeBSD xdr source compiles and runs on RTEMS without modification.

The original source was obtained from:
	ftp://ftp.FreeBSD.org/pub/FreeBSD/
		        branches/4.0-stable/src/lib/libc/rpc
			branches/4.0-stable/src/lib/libc/xdr
			branches/4.0-stable/src/include/rpc
			branches/4.0-stable/src/include/rpcsvc


On Feb 26, 2010, at 6:16 AM, Charles Wilson wrote:

> Ralf Corsepius wrote:
>> Neither did I have a look into the code, but some general
>> remarks/comments from the RTEMS side:
>> 
>> - RTEMS has an xdr port of its own (Originally derived from Sun RPC's
>> original code, but heavily modified since).
> 
> Really? Where? I didn't see anything like xdr in newlib...is it a
> standalone library?
> 
>> - XDR in general has a lot of portability issues, esp. wrt. "exotic
>> targets". Have these exotic targets been taken into account?
> 
> Yes -- in the sense that I chose to enable building libc/xdr/* only on
> cygwin.  So, "exotic" targets should be unaffected (*, **) by this new
> code, until/unless THEY choose to enable building it.
> 
> (*) except that, like stdio.h, rpc/types.h and rpc/xdr.h will be
> installed by 'make install' regardless of whether stdio/ or xdr/ is
> actually built.
> 
> (**) linux has a libc/sys/linux/include/rpc/xdr.h, even though the linux
> port doesn't provide the xdr routines. IIUC, machine specific headers
> will clobber generic ones, on make install. So, there's no real issue
> here for $host==linux until/unless the new xdr implementation is
> activated for that host.  In which case, it would probably make sense
> simply to remove libc/sys/linux/include/rpc/xdr.h (ditto rpc/types.h).
> 
>> - XDR is hardly useful for systems without networking support.
>> Has this consideration been taken into account (E.g. XDR not depending
>> on "networking routines".)
> 
> I disagree. My original motivation for investigating xdr was for
> platform-independent binary data storage, not networking.  But this
> implementation of XDR has been scrubbed of reliance on stuff like
> htons() (sometimes declared in asm/byteorder.h, or netinet/in.h, or
> winsock.h).
> 
> While often used (and provided alongside) RPC routines, XDR and RPC are
> actually quite well separated.  The only entanglement appears to be the
> following #defines, which I have removed from this version rpc/xdr.h:
> 
> #define xdr_rpcvers(xdrs, versp) xdr_u_int32(xdrs, versp)
> #define xdr_rpcprog(xdrs, progp) xdr_u_int32(xdrs, progp)
> #define xdr_rpcproc(xdrs, procp) xdr_u_int32(xdrs, procp)
> #define xdr_rpcprot(xdrs, protp) xdr_u_int32(xdrs, protp)
> #define xdr_rpcport(xdrs, portp) xdr_u_int32(xdrs, portp)
> 
> (Now, maybe those #defines should be added back, so that this xdr.h can
> be used without modification by naive RPC implementations which expect
> them...but that's a decision for another day).
> 
>> That said, I'd see your XDR works disabled for RTEMS at least for now
>> and/or to be optional (Preferably defaulting to off).
> 
> It is, and does.  (If not, it's a bug and I want to fix it).
> 
> --
> Chuck

-- 
Eric Norum
eric@norum.ca