Add xdr support

[Charles Wilson]

Christopher Faylor wrote:
> On Sat, Feb 13, 2010 at 10:20:20AM -0500, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> On Feb 13 01:43, Charles Wilson wrote:
>>>> The attached patch(es) add XDR support to cygwin
>>> Cool.
> 
> I didn't get Corinna's response in email and it isn't in the archive.
> I assume that was unintentional?

I didn't notice that her original response was private, until after I'd
already sent the reply.  I'm so used to having to mess with the To/From
fields when I deal with the cygwin lists -- since I use gmane for
reading -- that it has become automatic for me.  I must have done my
rote set-the-To-field-to-cygwin-patches thing 'in my sleep'.

I don't reckon it was a problem tho; I imagine Corinna actually intended
that message to be public. There's certainly nothing private about
critiquing patch submissions.

> The benefit of putting this in init.cc, or something called from
> init.cc, is that it will work better if cygwin is dynamically loaded.  I
> don't really care too much if that case works though.  If that was the
> intent then the function should be called from dll_crt0_0 rather than
> init.cc.
> 
> However, I probably agree with Corinna that it should go in dll_crt0_1.

I'm not concerned about that either. So, I can revise and put it into
dll_crt0_N (which: _0? _1?) -- but the disposition of the actual core
code: cygwin, newlib, or external lib -- needs to be resolved first.

> I have to wonder if these really belong in newlib.  I have an anti-newlib
> bias (not to be confused with the ficitious other biases that I've been
> accused of) so maybe it's that talking but it seems like you've gone to
> some effort to ensure that things work for the non-cygwin case.  Would
> it have been easier if you just imported everything into Cygwin?

Not /that/ much easier. I may have been able to avoid the whole
EXFUN()/DEFUN() thing, but that was rather mindless.  It's just a bunch
of C code that was already pretty thoroughly debugged and operational on
cygwin.

You may have missed the discussion -- you were on vacation at the time
-- but I raised this possibility as an aside last fall.  It was
definitely overkill for the problem under consideration at that time:

http://cygwin.com/ml/cygwin-developers/2009-10/msg00242.html
Re: Avoid collisions between parallel installations of Cygwin

[as part of the discussion on how to record "resource" information in
the DLL, or a separate file, or in the registry, controlling whether to
activate the "allow multiple cygwin1.dll" behavior]:
> I hesitate to suggest Yet Another Addition before 1.7.1 -- and cgf is
> gonna kill me when he gets back and reads this, whether we take action
> on it or not -- but there is a solution.  Cygwin will never directly
> support RPC, but there's no reason it can't implement the XDR primitives
> -- especially now that SUN has changed the license from (open but
> non-copyleft and arguably GPL-incompatible) to BSD.

IIRC at that time Corinna suggested that newlib was the appropriate
place for this, if I wanted to contribute it post-1.7.1. I asked how to
go about adding something to newlib that might not work for all targets,
and she said:
   > Sure.  Use a define to enable XDR in sys/config.h, e.g.
   >   #ifdef __CYGWIN__
   >   [...]
   >   #define _ENABLE_XDR_ 1
   >   #endif
Unfortunately, my google-foo is not strong enough to find that message
in the cygwin archives, and it doesn't appear anywhere in my own email
archives. The snippet above was taken from my porting notes file...  I
ultimately ended up using a different mechanism, one used elsewhere in
newlib, for enabling/disabling the XDR component, though.


Anyway, I can imagine that XDR support would be useful for other newlib
targets that might want to support data interchange. It would at least
simplify /some/ of the effort in writing RPC or NFS clients for those
platforms. Support for XDR encoding/decoding is part of glibc, after all...

Now, I didn't actually TEST this code on (e.g. RTEMS) targets. I figure
if the code is accepted by newlib, then other interested parties can
later activate it when they put in whatever minimal effort may be
required to get it to compile for them. (It's pretty dirt-simple C code;
build system integration and header file prereqs are actually the hard
part.  They might need to #ifdef out support for e.g. long longs or
doubles; maybe add some intelligence to optionally exclude those parts
of the XDR code that require stdio to work...but this would get them 90%
of the way there.  As submitted though, XDR is completely "turned off"
for all but $host cygwin).

> Also, follow-up question: Should this go into a different library
> entirely?  Is it time to think about not just making cygwin1.dll the
> monolithic one-stop-for-all-of-your-posix-api shared library?

Well...if it's in glibc or the *nix/bsd kernels, it probably belongs in
the cygwin DLL and not someplace else.  Packages which depend on the
functionality are unlikely to want to add -lfoo for cygwin, when they
can just use the "automatic" support provided by the system runtime
library on other platforms.

OTOH, we had -lminires for years, and adding "-lxdr" to LIBS is not THAT
hard for a cygwin maintainer of some client to do.  "bsd-xdr" is ready
to be ITP'ed as it is, if we'd rather go that way. (There's also
"PortableXDR" http://people.redhat.com/~rjones/portablexdr/, but that's
a from-scratch reimplementation under the LGPL and the whole reason to
use a non-copyleft source was so that it could go into newlib and/or
cygwin.  Unless Red Hat has some ownership over rjones' code?)

My *original* thought -- again, obvious overkill -- was that cygwin
itself could use XDR to store binary resource data.  Obviously (a)
that's not possible if the XDR support is in a separate DLL, and (b) I
don't think we have any intention of doing any such thing, so that is a
non-issue when considering where this XDR support should be located.


Either way, however, the new xdr functionality in cygwin1.dll or in
-lxdr may conflict with the (orphaned) sunrpc package, and may also
interfere with the (orphaned) nfs-server package.  I just realized this,
but it's something to consider. Personally, I'm not too fussed about
"breaking" orphaned packages; and they probably wouldn't "break" -- the
newer package's .h files in /usr/include/rpc/* will conflict but that's
about it.

--
Chuck