linux-os (Dick Johnson) wrote:
It makes no sense because a bitfield is something having to
do with a 'C' compiler and it must NEVER be used as a template
to address hardware! 'C' gives no guarantee of the ordering
within machine words. The only way you can access them is
using 'C'. They don't have addresses like other objects
(of course they do exist --somewhere). They are put into
"storage units," according to the standard, and these
storage units are otherwise undefined although you can
align them (don't go there).
Well, if it doesn't make any sense why do we have __LITTLE_ENDIAN_BITFIELD and
__BIG_ENDIAN_BITFIELD? That is, why do we do this:
#if defined(__BIG_ENDIAN_BITFIELD)
__u8 reserved1 : 2;
__u8 ili : 1;
__u8 reserved2 : 1;
__u8 sense_key : 4;
#elif defined(__LITTLE_ENDIAN_BITFIELD)
__u8 sense_key : 4;
__u8 reserved2 : 1;
__u8 ili : 1;
__u8 reserved1 : 2;
#endif
when we can just do this:
#if defined(__BIG_ENDIAN)
__u8 reserved1 : 2;
__u8 ili : 1;
__u8 reserved2 : 1;
__u8 sense_key : 4;
#elif defined(__LITTLE_ENDIAN)
__u8 sense_key : 4;
__u8 reserved2 : 1;
__u8 ili : 1;
__u8 reserved1 : 2;
#endif
If you want to call machine-control bits by name, just
define them as hexadecimal numbers (unsigned ints) and,
if your hardware is for both little/big endian, use
a macro that resolves the issue between the number
and the hardware.
That wasn't my intention. I was hoping that __LITTLE_ENDIAN_BITFIELD could be
used to test bit-endianness, but I guess it can't.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
