Marshalling code not properly dealing with endianess

Problems when trying to run the openhpid daemon on one
processor type (e.g. ppc big endian) and a client on
another type (e.g. x86 little endian)? When I tried
this in our environment with the most recent 2.5.2
OpenHpi release, I see the following erors on the
client side:

bash>: hpiinv -x
hpiinv ver 1.5 HPI-B
saHpiSessionOpen rv = 0 sessionid = 2
saHpiDomainInfoGet rv = -1014
Starting Discovery, pass 1 ...
saHpiDiscover rv = -1014
saHpiDiscover error -1014

I turned on verbose logging on the daemon and see the
following messages.

safhpi.c:72:saHpiSessionOpen: Created session 2 for
domain 1
safhpi.c:124:saHpiDomainInfoGet: Session 33554432 is
not valid
safhpi.c:92:saHpiDiscover: Session 33554432 is not valid
safhpi.c:81:saHpiSessionClose: Session 33554432 is not
valid

I tried several client commands and it appears that all
of them have problems with the sessionid for subsequent
APIs.

======
Renier Morales wrote:

> Definitely a problem with endianness. That number,
33554432, gives me 0x0000000002000000. I figure that is
where the Session Id 2 is ending up.
> This brings up an interesting problem. While we never
supported this, running the daemon in one arch and the
client in another, it would be a good feature to add.
Specially this year.
> But fixing this may not be a small thing. I think it
would require adjusting, or even rewriting, the
marshaling mechanism that is used to pass data from the
client to the daemon and back. It might even be a
chance to use a more platform/arch agnostic data
passing mechanism like XML.
> David, what do you think about this?
>
> --Renier

David Judkovics wrote:

> I expected the marshalling code to have dealt with
this. I think this configuration issue should be fixed
in code and moving to an XML based transport mechanism
would be nice.