On Thu, Jul 30, 2009 at 5:38 AM, Wojtek Meler <[email protected]> wrote: > Fabio M. Di Nitto pisze: > > On Thu, 2009-07-30 at 12:55 +0200, Wojtek Meler wrote: > > > >> Fabio M. Di Nitto pisze: > >> > >>> testcpg is not endian clean. That's why you see them backwards. > >>> > >>> > >> I thought that corosync handles endianess in corosync daemon, and > >> clients - like testcpg - > >> don't need to worry about it. Is it true? > >> > > > > No it´s not true. neither corosync or associated libraries have any idea > > of what kind of data you are transmitting over the wire. They can't > > randomly swab stuff around. > > > > > Sure, I was not clear - what I ment is services loaded in corosync > daemon (like service_cpg.lcrso) > handles endianess in their messages sent over the wire, but client > libraries (libcpg,so) > that communicate over coroipcc don't. > Messages from processes that are in CPG group are not touched (different > layer). > > If it is not I completely misunderstood corosync architecture. > > Regards, > Wojtek > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais >
My take on this is that totemsrp swabs the nodeid when it receives the message in a cross endian system, and delivers the byte swabbed nodeid to cpg. When autogeneration of node ids is used, you may expect that the node id is the 32 bit ip address in network byte order. Instead the node id is autogenerated in host byte order. We could ensure that the autogenerated node ids are always in little endian format (ie: swab them on big endian architectures) rather then a mix of little and big endian as is the case now in cross endian systems which makes understanding the content of the autogenerated nodeid impossible (and provides a possible collision of nodeids in an ipv4 network). Try this patch. If this doesn't solve it, a swab may be required in testcpg -i operations on BE arches. I could be entirely wrong about all this though. I'm not sure whether the node id is in BE or LE when generated. Whatever it is now, we can't swab during creation on LE architectures because to date LE has been our main focus and it would cause all sorts of compatibility breakage. Regards -steve
corosync-trunk-totem-autogen-le.patch
Description: Binary data
_______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
