On 05/20/2011 02:01 AM, Lars Marowsky-Bree wrote:
> On 2011-05-20T14:35:28, Jiaju Zhang <[email protected]> wrote:
>
> Hi Jiaju,
>
> thanks for the good work!
>
> I can't comment on totem much, but some general code only:
>
>> +#define ENDIAN_LOCAL 0xff22
>
> I am not sure about this one. Would it not make more sense to always
> convert to a known byte-order on sending the message (hence the name
> "network byte order") and convert incoming messages depending on the
> local byte order?
>
> (man htonl)
>
Lars,
Generally this is how network protocols are done, but for historic
reasons, we decided to do conversion on receipt of message rather then
origination (performance was better in a cross-endian system). openais
came from an embedded world where cross-endian wa svery common.
>> +struct message_header {
>> + char type;
>> + char encapsulated;
>> + unsigned short endian_detector;
>> + int ring_number;
>> + int nodeid_activator;
>> +} __attribute__((packed));
>
> Since size matters on the wire, I think you should use types from
> stdint.h (uint8_t, int32_t, etc).
>
> I'm also not quite sure if this could result in alignment errors on
> access on weird architectures such as ia64.
>
this header is from totemsrp.c
It does not cause alignment errors on that hardware currently.
Agree we should be using stdtyping throughout the entire source base -
something for future development. If I knew then what I know now, it
would be this way ;)
Regards
-steve
>
> Regards,
> Lars
>
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
