linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Guillaume Laurès" <guillaume.laures@noos.fr>
To: linuxppc-dev@lists.linuxppc.org
Cc: "Leonard N. Zubkoff" <lnz@dandelion.com>
Subject: another endianness issue...
Date: Sat, 23 Jun 2001 11:29:19 +0200	[thread overview]
Message-ID: <3B34616F.2090403@noos.fr> (raw)
In-Reply-To: 0106192003070C.00609@reality.internal

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

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

[-- Attachment #2: struct_endian.c --]
[-- Type: text/plain, Size: 1195 bytes --]

/**********************************************
 *                                            *
 * gcc -Wall struct_endian.c -o struct_endian *
 *                                            *
 **********************************************/

#include <stdio.h>
#include <endian.h>

#if __BYTE_ORDER == __LITTLE_ENDIAN
union byte {
  unsigned char all;
  struct {
    unsigned char zero:1;
    unsigned char one:1;
    unsigned char two:1;
    unsigned char three:1;
    unsigned char four:1;
    unsigned char five:1;
    unsigned char size:1;
    unsigned char seven:1;
  } split;
};
#elif __BYTE_ORDER == __BIG_ENDIAN
union byte {
  unsigned char all;
  struct {
    unsigned char seven:1;
    unsigned char size:1;
    unsigned char five:1;
    unsigned char four:1;
    unsigned char three:1;
    unsigned char two:1;
    unsigned char one:1;
    unsigned char zero:1;
  } split;
};
#endif


int main(void)
{
  union byte a;
  unsigned char c;

  a.all = 0x1;
  c = 0x1;

  printf("struct:\n");
  printf("  bit 0 = %u\n", a.split.zero);
  printf("  bit 7 = %u\n", a.split.seven);

  printf("char:\n");
  printf("  bit 0 = %u\n", c & 0x1);
  printf("  bit 7 = %u\n", c >> 7);

  return 0;
}


  parent reply	other threads:[~2001-06-23  9:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3B2E747A.6090607@noos.fr>
     [not found] ` <01061823464800.00690@reality.internal>
     [not found]   ` <3B2F0871.2070304@noos.fr>
     [not found]     ` <0106192003070C.00609@reality.internal>
2001-06-22 17:12       ` getting the 8600 to boot 2.4.5 Guillaume Laurès
2001-06-24  9:54         ` Michel Lanners
2001-06-24 11:39           ` Takashi Oe
2001-06-23  9:29       ` Guillaume Laurès [this message]
2001-06-23 18:19         ` another endianness issue Timothy A. Seufert
2001-06-23 18:33           ` Hollis
2001-06-23 23:22             ` Benjamin Herrenschmidt
2001-06-24 13:59           ` Guillaume Laurès
2001-06-24 14:50             ` Benjamin Herrenschmidt
2001-06-24 14:52             ` Geert Uytterhoeven
2001-06-24 22:49             ` Dan Malek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B34616F.2090403@noos.fr \
    --to=guillaume.laures@noos.fr \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=lnz@dandelion.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).