Re: linux-next: build warning in Linus'tree

[Joakim Tjernlund]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/