[RFC] #define __BYTE_ORDER
in [Kernel]
|
Prev: [PATCH 00/07] net: remove trailing spaces in messages
Next: [PATCH 5/7] wireless/prism54: remove trailing space in messages
From: Andrew Morton on 24 Mar 2010 14:30 On Wed, 17 Mar 2010 19:10:55 +0100 Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> wrote: > Linux does not define __BYTE_ORDER in its endian header files > which makes some header files bend backwards to get at the > current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h > to make it easier for header files that are used in user space too. I don't get it. Why not nuke __BYTE_ORDER altogether and do `#ifdef __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Geert Uytterhoeven on 24 Mar 2010 14:40 On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm(a)linux-foundation.org> wrote: > On Wed, 17 Mar 2010 19:10:55 +0100 > Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> wrote: > >> Linux does not define __BYTE_ORDER in its endian header files >> which makes some header files bend backwards to get at the >> current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h >> to make it easier for header files that are used in user space too. > > I don't get it. Why not nuke __BYTE_ORDER altogether and do `#ifdef > __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? Because in userspace the convention is that 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: David Daney on 24 Mar 2010 15:00 On 03/24/2010 11:37 AM, Geert Uytterhoeven wrote: > On Wed, Mar 24, 2010 at 19:21, Andrew Morton<akpm(a)linux-foundation.org> wrote: >> On Wed, 17 Mar 2010 19:10:55 +0100 >> Joakim Tjernlund<Joakim.Tjernlund(a)transmode.se> wrote: >> >>> Linux does not define __BYTE_ORDER in its endian header files >>> which makes some header files bend backwards to get at the >>> current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h >>> to make it easier for header files that are used in user space too. >> >> I don't get it. Why not nuke __BYTE_ORDER altogether and do `#ifdef >> __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? > > Because in userspace the convention is that > 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, > 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. > I have stumbled on this issue as well. However, consider this: If you make such a change, then you will start to see: #if __BYTE_ORDER == __BIG_ENDIAN appearing in kernel source code. Do we want two different endian checking idioms in the kernel? Or would it be just a single idiom, but one that is different than the status quo? The only time I can see that it makes a difference is if you want to share things like driver source code files between in-kernel drivers and userspace. A discussion of which, would probably provoke much discussion. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 24 Mar 2010 15:00 On Wed, 24 Mar 2010 19:37:36 +0100 Geert Uytterhoeven <geert(a)linux-m68k.org> wrote: > On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm(a)linux-foundation.org> wrote: > > On Wed, 17 Mar 2010 19:10:55 +0100 > > Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> wrote: > > > >> Linux does not define __BYTE_ORDER in its endian header files > >> which makes some header files bend backwards to get at the > >> current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h > >> to make it easier for header files that are used in user space too. > > > > I don't get it. __Why not nuke __BYTE_ORDER altogether and do `#ifdef > > __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? > > Because in userspace the convention is that > 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, > 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. umph. We don't _have_ to copy userspace, and removing __BYTE_ORDER altogether makes the kernel cleaner and simpler. But if we did that, we shouldn't have used the same symbols as userspace. Sigh. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joakim Tjernlund on 24 Mar 2010 17:50
geert.uytterhoeven(a)gmail.com wrote on 2010/03/24 19:37:36: > > On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm(a)linux-foundation.org> wrote: > > On Wed, 17 Mar 2010 19:10:55 +0100 > > Joakim Tjernlund <Joakim.Tjernlund(a)transmode.se> wrote: > > > >> Linux does not define __BYTE_ORDER in its endian header files > >> which makes some header files bend backwards to get at the > >> current endian. Lets #define __BYTE_ORDER in big_endian.h/litte_endian.h > >> to make it easier for header files that are used in user space too. > > > > I don't get it. �Why not nuke __BYTE_ORDER altogether and do `#ifdef > > __LITTLE_ENDIAN' and `#ifdef __BIG_ENDIAN' everywhere? > > Because in userspace the convention is that > 1. _both_ __LITTLE_ENDIAN and __BIG_ENDIAN are defined, > 2. you have to test for e.g. __BYTE_ORDER == __BIG_ENDIAN. Precisely, I see that i forgot to mention that in the commit msg. It is actually worse that that, gcc will only define one of __LITTLE_ENDIAN/__BIG_ENDIAN so you might be tricked that using just the __LITTLE_ENDIAN/__BIG_ENDIAN defines works. Then you add some include file such as stdlib.h and it all breaks because now both __LITTLE_ENDIAN and __BIG_ENDIAN are defined. Jocke -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |