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