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