> Hi guys,
> 
> when using QNet to communicate between CPUs of differing endianness,
> which endianness conversions are done automatically and which must I do myself
> ?

See "lib/c/resmgr/resmgr_endian.c" for what is handled automatically.  Generally you're on our own for content following
 DEVCTL and IOMSG headers (since there is no generic/defined format).

> As an example:
> I want to send a proprietary message to the server. I build that message:
> 	reg_msg.io_msg_hdr.type = _IO_MSG;
> 	reg_msg.io_msg_hdr.combine_len = ...;
> 	reg_msg.io_msg_hdr.mgrid = _IOMGR_IO_...;
> 	reg_msg.io_msg_hdr.subtype = ...;
> Those values are all uint16, so they need conversion.
> This means that the Framework will convert these values, otherwise I couldn't 
> check for the type on the destination CPU - correct? What about mgrid and 
> subtype, are those converted as well?

The internal framework converts all the header fields (type, len, mgrid and subtype).  It is your responsibility to 
convert the rest based on the private content format (presumably identified by the mgrid/subtype pairing).

> What about registering and sending Pulses...?
> I initialize the pulse using SIGEV_PULSE_INIT() and send it to the Server 
> using MsgSend() with a special message type (proprietary). The pulse code will
>  be the same on both CPUs, as it is 8 bits, so no problems with the endianness
>  here.
> What about the pulse value? Will it be swapped by the MsgDeliverEvent()? 

My understanding is that the network/transport layer (npm-qnet) handles the endianisation of such kernel data structures
 in direct kercalls, but xtang would have to confirm.