[PATCH] [RFC] #define __BYTE_ORDER

[PATCH] [RFC] #define __BYTE_ORDER

[Joakim Tjernlund]

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.

This patch has not been tested so watch out for breakage.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
---
 arch/alpha/math-emu/sfp-util.h          |    5 -----
 arch/powerpc/include/asm/sfp-machine.h  |    6 ------
 arch/s390/include/asm/sfp-util.h        |    2 --
 arch/sh/math-emu/sfp-util.h             |    4 ----
 arch/sparc/math-emu/sfp-util_32.h       |    6 ------
 arch/sparc/math-emu/sfp-util_64.h       |    6 ------
 arch/x86/boot/compressed/relocs.c       |    4 ++--
 include/linux/byteorder/big_endian.h    |    3 +++
 include/linux/byteorder/little_endian.h |    3 +++
 9 files changed, 8 insertions(+), 31 deletions(-)

diff --git a/arch/alpha/math-emu/sfp-util.h b/arch/alpha/math-emu/sfp-util.h
index f53707f..d4c6ae7 100644
--- a/arch/alpha/math-emu/sfp-util.h
+++ b/arch/alpha/math-emu/sfp-util.h
@@ -28,8 +28,3 @@ extern unsigned long __udiv_qrnnd (unsigned long *, unsigned long,
 #define UDIV_NEEDS_NORMALIZATION 1  
 
 #define abort()			goto bad_insn
-
-#ifndef __LITTLE_ENDIAN
-#define __LITTLE_ENDIAN -1
-#endif
-#define __BYTE_ORDER __LITTLE_ENDIAN
diff --git a/arch/powerpc/include/asm/sfp-machine.h b/arch/powerpc/include/asm/sfp-machine.h
index 3a7a67a..8b8fab9 100644
--- a/arch/powerpc/include/asm/sfp-machine.h
+++ b/arch/powerpc/include/asm/sfp-machine.h
@@ -353,12 +353,6 @@
 #define abort()								\
 	return 0
 
-#ifdef __BIG_ENDIAN
-#define __BYTE_ORDER __BIG_ENDIAN
-#else
-#define __BYTE_ORDER __LITTLE_ENDIAN
-#endif
-
 /* Exception flags. */
 #define EFLAG_INVALID		(1 << (31 - 2))
 #define EFLAG_OVERFLOW		(1 << (31 - 3))
diff --git a/arch/s390/include/asm/sfp-util.h b/arch/s390/include/asm/sfp-util.h
index 0addc64..7d43fee 100644
--- a/arch/s390/include/asm/sfp-util.h
+++ b/arch/s390/include/asm/sfp-util.h
@@ -73,5 +73,3 @@ extern unsigned long __udiv_qrnnd (unsigned int *, unsigned int,
 #define UDIV_NEEDS_NORMALIZATION 0
 
 #define abort() return 0
-
-#define __BYTE_ORDER __BIG_ENDIAN
diff --git a/arch/sh/math-emu/sfp-util.h b/arch/sh/math-emu/sfp-util.h
index 8ae1bd3..e852602 100644
--- a/arch/sh/math-emu/sfp-util.h
+++ b/arch/sh/math-emu/sfp-util.h
@@ -66,7 +66,3 @@
   } while (0)
 
 #define abort()	return 0
-
-#define __BYTE_ORDER __LITTLE_ENDIAN
-
-
diff --git a/arch/sparc/math-emu/sfp-util_32.h b/arch/sparc/math-emu/sfp-util_32.h
index d1b2aff..0ea35af 100644
--- a/arch/sparc/math-emu/sfp-util_32.h
+++ b/arch/sparc/math-emu/sfp-util_32.h
@@ -107,9 +107,3 @@
 
 #define abort()								\
 	return 0
-
-#ifdef __BIG_ENDIAN
-#define __BYTE_ORDER __BIG_ENDIAN
-#else
-#define __BYTE_ORDER __LITTLE_ENDIAN
-#endif
diff --git a/arch/sparc/math-emu/sfp-util_64.h b/arch/sparc/math-emu/sfp-util_64.h
index 425d3cf..d17c9bc 100644
--- a/arch/sparc/math-emu/sfp-util_64.h
+++ b/arch/sparc/math-emu/sfp-util_64.h
@@ -112,9 +112,3 @@
 
 #define abort() \
 	return 0
-
-#ifdef __BIG_ENDIAN
-#define __BYTE_ORDER __BIG_ENDIAN
-#else
-#define __BYTE_ORDER __LITTLE_ENDIAN
-#endif
diff --git a/arch/x86/boot/compressed/relocs.c b/arch/x86/boot/compressed/relocs.c
index 89bbf4e..7b1aaa2 100644
--- a/arch/x86/boot/compressed/relocs.c
+++ b/arch/x86/boot/compressed/relocs.c
@@ -195,11 +195,11 @@ static const char *sym_name(const char *sym_strtab, Elf32_Sym *sym)
 
 
 
-#if BYTE_ORDER == LITTLE_ENDIAN
+#if __BYTE_ORDER == __LITTLE_ENDIAN
 #define le16_to_cpu(val) (val)
 #define le32_to_cpu(val) (val)
 #endif
-#if BYTE_ORDER == BIG_ENDIAN
+#if __BYTE_ORDER == __BIG_ENDIAN
 #define le16_to_cpu(val) bswap_16(val)
 #define le32_to_cpu(val) bswap_32(val)
 #endif
diff --git a/include/linux/byteorder/big_endian.h b/include/linux/byteorder/big_endian.h
index 3c80fd7..d53a67d 100644
--- a/include/linux/byteorder/big_endian.h
+++ b/include/linux/byteorder/big_endian.h
@@ -7,6 +7,9 @@
 #ifndef __BIG_ENDIAN_BITFIELD
 #define __BIG_ENDIAN_BITFIELD
 #endif
+#ifndef __BYTE_ORDER
+#define __BYTE_ORDER __BIG_ENDIAN
+#endif
 
 #include <linux/types.h>
 #include <linux/swab.h>
diff --git a/include/linux/byteorder/little_endian.h b/include/linux/byteorder/little_endian.h
index 83195fb..f7f8ad1 100644
--- a/include/linux/byteorder/little_endian.h
+++ b/include/linux/byteorder/little_endian.h
@@ -7,6 +7,9 @@
 #ifndef __LITTLE_ENDIAN_BITFIELD
 #define __LITTLE_ENDIAN_BITFIELD
 #endif
+#ifndef __BYTE_ORDER
+#define __BYTE_ORDER __LITTLE_ENDIAN
+#endif
 
 #include <linux/types.h>
 #include <linux/swab.h>
-- 
1.6.4.4

Re: [PATCH] [RFC] #define __BYTE_ORDER

[Andrew Morton]

On Wed, 17 Mar 2010 19:10:55 +0100
Joakim Tjernlund <Joakim.Tjernlund@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?

Re: [PATCH] [RFC] #define __BYTE_ORDER

[Geert Uytterhoeven]

On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Wed, 17 Mar 2010 19:10:55 +0100
> Joakim Tjernlund <Joakim.Tjernlund@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@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

Re: [PATCH] [RFC] #define __BYTE_ORDER

[Andrew Morton]

On Wed, 24 Mar 2010 19:37:36 +0100
Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 17 Mar 2010 19:10:55 +0100
> > Joakim Tjernlund <Joakim.Tjernlund@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.

Re: [PATCH] [RFC] #define __BYTE_ORDER

[David Daney]

On 03/24/2010 11:37 AM, Geert Uytterhoeven wrote:
> On Wed, Mar 24, 2010 at 19:21, Andrew Morton<akpm@linux-foundation.org>  wrote:
>> On Wed, 17 Mar 2010 19:10:55 +0100
>> Joakim Tjernlund<Joakim.Tjernlund@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

Re: [PATCH] [RFC] #define __BYTE_ORDER

[Joakim Tjernlund]

geert.uytterhoeven@gmail.com wrote on 2010/03/24 19:37:36:
>
> On Wed, Mar 24, 2010 at 19:21, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Wed, 17 Mar 2010 19:10:55 +0100
> > Joakim Tjernlund <Joakim.Tjernlund@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

Re: [PATCH] [RFC] #define __BYTE_ORDER

[Joakim Tjernlund]

David Daney <ddaney@caviumnetworks.com> wrote on 2010/03/24 19:53:13:
>
> On 03/24/2010 11:37 AM, Geert Uytterhoeven wrote:
> > On Wed, Mar 24, 2010 at 19:21, Andrew Morton<akpm@linux-foundation.org>  wrote:
> >> On Wed, 17 Mar 2010 19:10:55 +0100
> >> Joakim Tjernlund<Joakim.Tjernlund@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?

>From my patch you already see that there some ugliness in header files because
one wants to use them in user space too. I don't think inventing a kernel
specific idiom will by us anything. To keep the confusion down it is
better to just use #if __BYTE_ORDER == __BIG_ENDIAN all over.

>
> 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.

Yes, I stumbled over this when I moved crc32.c to run the test routine
included in there. Took me quite a while to figure out what was wrong
because you don't even get a warning, it just silently breaks.