Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote on 2010/05/26 17:29:02:
>
> On Wed, 26 May 2010, Joakim Tjernlund wrote:
> >
> > If my suggestion above works, then one could start transforming current uses
> of __BYTE_ORDER,
> > into similar constructs and once all are done, #define both __LITTLE_ENDIAN/
> __BIG_ENDIAN and
> > move back to #if __BYTE_ORDER == __LITTLE_ENDIAN
>
> No. Don't do it. Why the hell would we want to use the inferior model?
I agree that the glibc model(dunno if this is glibc/gcc specific or some standard)
is less than optimal but the linux model has two major flaws too:
1) It silently breaks when neither of {__LITTLE_,__BIG}_ENDIAN (or both)are
defined depending on the endianess of the target CPU.
The glibc model generates a compile error if you forget to include __BYTE_ORDER.
2) It clashes with user space so one cannot use it in exported header files.
If you grep for __BYTE_ORDER in the kernel you will find some ugly #ifdefs
to overcome 2). It would have been somewhat better if linux had defined its own
names instead of reusing the glibc/gcc names with different semantics.
1) is worse and the reason for this patch. I moved lib/crc32.c
to user space so I could run the builtin unit test program because
I wanted to do some optimizations. It just silently broke depending
on the endianess of the CPU. Took half a day to figure out why :(
This could easily happen in the kernel too.
Jocke
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
