another endianness issue...
Guillaume Laurès
guillaume.laures at noos.fr
Sat Jun 23 19:29:19 EST 2001
Hello all,
I've tracked down the problem with the DAC960 driver (drivers/block), a
module that handles the mylex range of raid cards.
All the structures dealing with the card sound like this one:
typedef union DAC960_LA_InboundDoorBellRegister
{
unsigned char All;
struct {
boolean HardwareMailboxNewCommand:1; /* Bit 0 */
boolean AcknowledgeHardwareMailboxStatus:1; /* Bit 1 */
boolean GenerateInterrupt:1; /* Bit 2 */
boolean ControllerReset:1; /* Bit 3 */
boolean MemoryMailboxNewCommand:1; /* Bit 4 */
unsigned char :3; /* Bits 5-7 */
} Write;
struct {
boolean HardwareMailboxEmpty:1; /* Bit 0 */
boolean InitializationNotInProgress:1; /* Bit 1 */
unsigned char :6; /* Bits 2-7 */
} Read;
}
DAC960_LA_InboundDoorBellRegister_T
And I guess on ppc we would need all the bits line reversed.
So, my question is how to handle this in the best approach, the goal
being a unified driver nt too difficult to maintain
I've attached a little sample written by hollis that reproduces the
problem. I've managed to get gcc choose the right structure according to
the endianness of the host with endian.h and a couple of #ifdef, but
this is still rather bad since we have to maintain two versions of the
structs.
Does antbody has a good idea on this or an example of driver we could
follow ?
Thanks,
GoM
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: struct_endian.c
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20010623/1132c23b/attachment.txt>
More information about the Linuxppc-dev
mailing list