[OpenAFS-devel] xdr renaming

[Derrick Brashear]

On Mon, Aug 17, 2009 at 12:51 PM, Andrew Deason<adeason@sinenomine.net> wrote:
> In rx/xdr.h, we conditionally rename pretty much all xdr routines for
> primitive types from xdr_foo to afs_xdr_foo. From reading commit
> messages, I gather this is just in cases where we can't use the builtin
> xdr routines for whatever reason.

the reason at the time was type conflicts; notably, we did 64 bit
stuff before some platforms did, so we
ended up in situations where we had a mismatch when (or if) those
platforms came along; then there were
also cases where memory allocation caused an issue.

> This is causing me a small headache. For some libuafs experimentation,
> I'm trying to link both libuafs and libsys in the same binary. This
> normally works fine, but specifically on amd64 linux this causes linking
> problems, because only on there (and darwin, and (kernel && !ukernel))
> we rename the xdr_foo symbols. libsys uses some xdr_foo functions, and
> libuafs doesn't have them defined, since it doesn't include xdr.o or
> xdr_array.o.
>
> On non-amd64linux, libsys just uses the built-in xdr_foo in libc, so
> it's fine. On amd64 linux, libsys looks for afs_xdr_foo and doesn't see
> any. With some minor finagling, I can get xdr{,_array}.o in libuafs, and
> can force the xdr renames, so it can be made to work.
>
> To make this easier, can we just unconditionally #define xdr_foo
> afs_xdr_foo? Is there any situation where we may not want to do that?

It means that potentially we lose the ability to use an optimized
xdr_* on a platform where we are nominally able to use it; we could
wrap afs_xdr_* around xdr_* on those platforms as a dodge on this if
we care.

It may not be worth caring.

Secondary concern: testing the change on all the platforms.

Derrick