[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bluetooth-dev] Re: Porting to ARM




This is a problem if the structure is being applied to data received
by some other source.  In the example,

#ifdef __LITTLE_ENDIAN
        u32 ocf:10;
        u32 ogf:6;
#elifdef __BIG_ENDIAN
        u32 ogf:6;
        u32 ocf:10;
#else

Data should come in [ocf(2)ogf(6)][ocf(8)].  However, a big endian
processor would expect [ocf(8)][ocf(2)ogf(6)].  The value as a 16
bit quantity needs to go through a translation.  You could do this
with a union.  Here is an example,

union something {
        struct foo{
                u32 ogf:6;
                u32 ocf:10;
        },
        u16 raw;
}

When reading, the value must be run through a bluetooth swap function.
Then the other software can use the ogf,ocf as they like.  There is no
need for bit operations.

Byte order shouldn't effect anything other than values retrieved from
devices (network, floppy, USB, etc).  Once the value is in the
machine, things shouldn't have to be manipulated.

A danger with turning on global structure alignments is that other
code may rely on a different structure packing (ie some kernel data?).

hth,
Bill

>>>>> "Norman" == Norman Farquhar <norman_farquhar@xxxxxxx.com> writes:

 Norman> Gordon, Just happened to see this exchange.  I do not know
 Norman> the details of the headers, but these comments seem strange
 Norman> to me.

 Norman> Correct me if I am wrong, but the endianness does not affect
 Norman> the order of bits within a byte.  It only affects the order
 Norman> of the bytes within larger data units.  Now some
 Norman> communications devices prescribe the order of the bits, but
 Norman> that is usually hidden from the high level code by doing
 Norman> converting to a properly bit ordered byte stream.

 Norman> Are the Bluetooth headers defining reversed bit fields?