* Compiling glibc with 2.6.28 linux headers
@ 2008-12-13 15:55 Friedrich Oslage
2008-12-16 9:13 ` David Miller
0 siblings, 1 reply; 21+ messages in thread
From: Friedrich Oslage @ 2008-12-13 15:55 UTC (permalink / raw)
To: sparclinux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
when compiling glibc(2.9, 20081208 snapshot) with linux 2.6.28-rc8
headers I get a lot of errors like this one:
In file included from
/tmp/toolchain-build/rootfs/usr/include/asm/byteorder.h:49,
from
/tmp/toolchain-build/rootfs/usr/include/linux/atalk.h:4,
from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
from ../sysdeps/unix/sysv/linux/sa_len.c:22:
/tmp/toolchain-build/rootfs/usr/include/linux/byteorder.h:8:3: error:
#error Fix asm/byteorder.h to define one endianness
About a month ago arch/sparc/include/asm/byteorder.h was changed to
include the new linux/byteorder.h instead of the old
linux/byteorder/big_endian.h. The new one panics if both __LITTLE_ENDIAN
and __BIG_ENDIAN are defined.
But since glibc's string/endian.h(/usr/include/endian.h) always defines
__BIG_ENDIAN and __LITTLE_ENDIAN it may occur, depending on the
includes, that both are defined when asm/byteorder.h is included.
My assumption is that asm/byteorder.h should ensure that only one of
these is defined.
After applying the patch below compiling glibc works again. But when
compiling the kernel I get
In file included from drivers/scsi/qla2xxx/qla_dfs.c:7:
drivers/scsi/qla2xxx/qla_def.h:1487:7: warning: "__LITTLE_ENDIAN" is not
defined
Which sould be okay...I think the #elif should really be an #elif
defined but that's another thing ;)
Is this the right solution or did I miss anything?
Cheers,
Friedrich
- --- arch/sparc/include/asm/byteorder.h
+++ arch/sparc/include/asm/byteorder.h
@@ -5,6 +5,9 @@
#include <asm/asi.h>
#define __BIG_ENDIAN
+#ifdef __LITTLE_ENDIAN
+# undef __LITTLE_ENDIAN
+#endif
#ifdef CONFIG_SPARC32
#define __SWAB_64_THRU_32__
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAklD2tYACgkQknxn9PmJ76XvEACZAajpv/iRLAeEHXp7cIWBCEEX
V9kAnRZ0BBDwLrMENDsPsYMuPWpLDlKv
HUQ
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Compiling glibc with 2.6.28 linux headers
2008-12-13 15:55 Compiling glibc with 2.6.28 linux headers Friedrich Oslage
@ 2008-12-16 9:13 ` David Miller
0 siblings, 0 replies; 21+ messages in thread
From: David Miller @ 2008-12-16 9:13 UTC (permalink / raw)
To: bluebird; +Cc: sparclinux, linux-kernel, harvey.harrison
From: Friedrich Oslage <bluebird@gentoo.org>
Date: Sat, 13 Dec 2008 16:55:02 +0100
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> when compiling glibc(2.9, 20081208 snapshot) with linux 2.6.28-rc8
> headers I get a lot of errors like this one:
>
> In file included from
> /tmp/toolchain-build/rootfs/usr/include/asm/byteorder.h:49,
> from
> /tmp/toolchain-build/rootfs/usr/include/linux/atalk.h:4,
> from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
> from ../sysdeps/unix/sysv/linux/sa_len.c:22:
> /tmp/toolchain-build/rootfs/usr/include/linux/byteorder.h:8:3: error:
> #error Fix asm/byteorder.h to define one endianness
Harvey, we might need to do something about this.
> About a month ago arch/sparc/include/asm/byteorder.h was changed to
> include the new linux/byteorder.h instead of the old
> linux/byteorder/big_endian.h. The new one panics if both __LITTLE_ENDIAN
> and __BIG_ENDIAN are defined.
>
> But since glibc's string/endian.h(/usr/include/endian.h) always defines
> __BIG_ENDIAN and __LITTLE_ENDIAN it may occur, depending on the
> includes, that both are defined when asm/byteorder.h is included.
>
> My assumption is that asm/byteorder.h should ensure that only one of
> these is defined.
>
> After applying the patch below compiling glibc works again. But when
> compiling the kernel I get
>
> In file included from drivers/scsi/qla2xxx/qla_dfs.c:7:
> drivers/scsi/qla2xxx/qla_def.h:1487:7: warning: "__LITTLE_ENDIAN" is not
> defined
>
> Which sould be okay...I think the #elif should really be an #elif
> defined but that's another thing ;)
>
> Is this the right solution or did I miss anything?
>
> Cheers,
> Friedrich
>
> - --- arch/sparc/include/asm/byteorder.h
> +++ arch/sparc/include/asm/byteorder.h
> @@ -5,6 +5,9 @@
> #include <asm/asi.h>
>
> #define __BIG_ENDIAN
> +#ifdef __LITTLE_ENDIAN
> +# undef __LITTLE_ENDIAN
> +#endif
>
> #ifdef CONFIG_SPARC32
> #define __SWAB_64_THRU_32__
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklD2tYACgkQknxn9PmJ76XvEACZAajpv/iRLAeEHXp7cIWBCEEX
> V9kAnRZ0BBDwLrMENDsPsYMuPWpLDlKv
> =48UQ
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Compiling glibc with 2.6.28 linux headers
@ 2008-12-16 9:13 ` David Miller
0 siblings, 0 replies; 21+ messages in thread
From: David Miller @ 2008-12-16 9:13 UTC (permalink / raw)
To: bluebird; +Cc: sparclinux, linux-kernel, harvey.harrison
From: Friedrich Oslage <bluebird@gentoo.org>
Date: Sat, 13 Dec 2008 16:55:02 +0100
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> when compiling glibc(2.9, 20081208 snapshot) with linux 2.6.28-rc8
> headers I get a lot of errors like this one:
>
> In file included from
> /tmp/toolchain-build/rootfs/usr/include/asm/byteorder.h:49,
> from
> /tmp/toolchain-build/rootfs/usr/include/linux/atalk.h:4,
> from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
> from ../sysdeps/unix/sysv/linux/sa_len.c:22:
> /tmp/toolchain-build/rootfs/usr/include/linux/byteorder.h:8:3: error:
> #error Fix asm/byteorder.h to define one endianness
Harvey, we might need to do something about this.
> About a month ago arch/sparc/include/asm/byteorder.h was changed to
> include the new linux/byteorder.h instead of the old
> linux/byteorder/big_endian.h. The new one panics if both __LITTLE_ENDIAN
> and __BIG_ENDIAN are defined.
>
> But since glibc's string/endian.h(/usr/include/endian.h) always defines
> __BIG_ENDIAN and __LITTLE_ENDIAN it may occur, depending on the
> includes, that both are defined when asm/byteorder.h is included.
>
> My assumption is that asm/byteorder.h should ensure that only one of
> these is defined.
>
> After applying the patch below compiling glibc works again. But when
> compiling the kernel I get
>
> In file included from drivers/scsi/qla2xxx/qla_dfs.c:7:
> drivers/scsi/qla2xxx/qla_def.h:1487:7: warning: "__LITTLE_ENDIAN" is not
> defined
>
> Which sould be okay...I think the #elif should really be an #elif
> defined but that's another thing ;)
>
> Is this the right solution or did I miss anything?
>
> Cheers,
> Friedrich
>
> - --- arch/sparc/include/asm/byteorder.h
> +++ arch/sparc/include/asm/byteorder.h
> @@ -5,6 +5,9 @@
> #include <asm/asi.h>
>
> #define __BIG_ENDIAN
> +#ifdef __LITTLE_ENDIAN
> +# undef __LITTLE_ENDIAN
> +#endif
>
> #ifdef CONFIG_SPARC32
> #define __SWAB_64_THRU_32__
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAklD2tYACgkQknxn9PmJ76XvEACZAajpv/iRLAeEHXp7cIWBCEEX
> V9kAnRZ0BBDwLrMENDsPsYMuPWpLDlKv
> HUQ
> -----END PGP SIGNATURE-----
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Compiling glibc with 2.6.28 linux headers
2008-12-16 9:13 ` David Miller
@ 2008-12-17 1:22 ` Harvey Harrison
-1 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-17 1:22 UTC (permalink / raw)
To: David Miller; +Cc: bluebird, sparclinux, linux-kernel
On Tue, 2008-12-16 at 01:13 -0800, David Miller wrote:
> From: Friedrich Oslage <bluebird@gentoo.org>
> Date: Sat, 13 Dec 2008 16:55:02 +0100
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > when compiling glibc(2.9, 20081208 snapshot) with linux 2.6.28-rc8
> > headers I get a lot of errors like this one:
> >
> > In file included from
> > /tmp/toolchain-build/rootfs/usr/include/asm/byteorder.h:49,
> > from
> > /tmp/toolchain-build/rootfs/usr/include/linux/atalk.h:4,
> > from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
> > from ../sysdeps/unix/sysv/linux/sa_len.c:22:
> > /tmp/toolchain-build/rootfs/usr/include/linux/byteorder.h:8:3: error:
> > #error Fix asm/byteorder.h to define one endianness
>
> Harvey, we might need to do something about this.
I'm on the run today, will take a look in 24 hours.
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Compiling glibc with 2.6.28 linux headers
@ 2008-12-17 1:22 ` Harvey Harrison
0 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-17 1:22 UTC (permalink / raw)
To: David Miller; +Cc: bluebird, sparclinux, linux-kernel
On Tue, 2008-12-16 at 01:13 -0800, David Miller wrote:
> From: Friedrich Oslage <bluebird@gentoo.org>
> Date: Sat, 13 Dec 2008 16:55:02 +0100
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > when compiling glibc(2.9, 20081208 snapshot) with linux 2.6.28-rc8
> > headers I get a lot of errors like this one:
> >
> > In file included from
> > /tmp/toolchain-build/rootfs/usr/include/asm/byteorder.h:49,
> > from
> > /tmp/toolchain-build/rootfs/usr/include/linux/atalk.h:4,
> > from ../sysdeps/unix/sysv/linux/netatalk/at.h:25,
> > from ../sysdeps/unix/sysv/linux/sa_len.c:22:
> > /tmp/toolchain-build/rootfs/usr/include/linux/byteorder.h:8:3: error:
> > #error Fix asm/byteorder.h to define one endianness
>
> Harvey, we might need to do something about this.
I'm on the run today, will take a look in 24 hours.
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-16 9:13 ` David Miller
@ 2008-12-18 1:46 ` Harvey Harrison
-1 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-18 1:46 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: bluebird, sparclinux, linux-kernel, David Miller
glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
which was tripping the check in linux/byteorder.h. Let's
just stay out of userspace's way and use __KERN_{endian}
The old implementation got away with it as it kept the two
implementations in different headers and conditionally included
the right one. The combined header does checks within each
function body and depends on only one being defined.
Converted the arches in mainline that have already moved to the
new header, as the other arches merge the will need simlar
fixups.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/avr32/include/asm/byteorder.h | 2 +-
arch/mips/include/asm/byteorder.h | 4 +-
arch/sh/include/asm/byteorder.h | 4 +-
arch/sparc/include/asm/byteorder.h | 2 +-
include/linux/byteorder.h | 84 ++++++++++++++++++------------------
5 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/arch/avr32/include/asm/byteorder.h b/arch/avr32/include/asm/byteorder.h
index 8e3af02..b7d6dd1 100644
--- a/arch/avr32/include/asm/byteorder.h
+++ b/arch/avr32/include/asm/byteorder.h
@@ -7,7 +7,7 @@
#include <asm/types.h>
#include <linux/compiler.h>
-#define __BIG_ENDIAN
+#define __KERN_BIG_ENDIAN
#define __SWAB_64_THRU_32__
#ifdef __CHECKER__
diff --git a/arch/mips/include/asm/byteorder.h b/arch/mips/include/asm/byteorder.h
index 2988d29..8ad8a5b 100644
--- a/arch/mips/include/asm/byteorder.h
+++ b/arch/mips/include/asm/byteorder.h
@@ -12,9 +12,9 @@
#include <asm/types.h>
#if defined(__MIPSEB__)
-# define __BIG_ENDIAN
+# define __KERN_BIG_ENDIAN
#elif defined(__MIPSEL__)
-# define __LITTLE_ENDIAN
+# define __KERN_LITTLE_ENDIAN
#else
# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
#endif
diff --git a/arch/sh/include/asm/byteorder.h b/arch/sh/include/asm/byteorder.h
index f5fa065..4aa5f1d 100644
--- a/arch/sh/include/asm/byteorder.h
+++ b/arch/sh/include/asm/byteorder.h
@@ -9,9 +9,9 @@
#include <linux/types.h>
#ifdef __LITTLE_ENDIAN__
-# define __LITTLE_ENDIAN
+# define __KERN_LITTLE_ENDIAN
#else
-# define __BIG_ENDIAN
+# define __KERN_BIG_ENDIAN
#endif
#define __SWAB_64_THRU_32__
diff --git a/arch/sparc/include/asm/byteorder.h b/arch/sparc/include/asm/byteorder.h
index 5a70f13..5b8347e 100644
--- a/arch/sparc/include/asm/byteorder.h
+++ b/arch/sparc/include/asm/byteorder.h
@@ -4,7 +4,7 @@
#include <asm/types.h>
#include <asm/asi.h>
-#define __BIG_ENDIAN
+#define __KERN_BIG_ENDIAN
#ifdef CONFIG_SPARC32
#define __SWAB_64_THRU_32__
diff --git a/include/linux/byteorder.h b/include/linux/byteorder.h
index 29f002d..3599fbc 100644
--- a/include/linux/byteorder.h
+++ b/include/linux/byteorder.h
@@ -4,33 +4,33 @@
#include <linux/types.h>
#include <linux/swab.h>
-#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
+#if defined(__KERN_LITTLE_ENDIAN) && defined(__KERN_BIG_ENDIAN)
# error Fix asm/byteorder.h to define one endianness
#endif
-#if !defined(__LITTLE_ENDIAN) && !defined(__BIG_ENDIAN)
+#if !defined(__KERN_LITTLE_ENDIAN) && !defined(__KERN_BIG_ENDIAN)
# error Fix asm/byteorder.h to define arch endianness
#endif
-#ifdef __LITTLE_ENDIAN
-# undef __LITTLE_ENDIAN
-# define __LITTLE_ENDIAN 1234
+#ifdef __KERN_LITTLE_ENDIAN
+# ifndef __LITTLE_ENDIAN
+# define __LITTLE_ENDIAN 1234
+# endif
+# ifndef __LITTLE_ENDIAN_BITFIELD
+# define __LITTLE_ENDIAN_BITFIELD
+# endif
#endif
-#ifdef __BIG_ENDIAN
-# undef __BIG_ENDIAN
-# define __BIG_ENDIAN 4321
+#ifdef __KERN_BIG_ENDIAN
+# ifndef __BIG_ENDIAN
+# define __BIG_ENDIAN 4321
+# endif
+# ifndef __BIG_ENDIAN_BITFIELD
+# define __BIG_ENDIAN_BITFIELD
+# endif
#endif
-#if defined(__LITTLE_ENDIAN) && !defined(__LITTLE_ENDIAN_BITFIELD)
-# define __LITTLE_ENDIAN_BITFIELD
-#endif
-
-#if defined(__BIG_ENDIAN) && !defined(__BIG_ENDIAN_BITFIELD)
-# define __BIG_ENDIAN_BITFIELD
-#endif
-
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
# define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
# define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
# define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
@@ -46,7 +46,7 @@
# define __cpu_to_be64(x) ((__force __be64)__swab64(x))
#endif
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
# define __be16_to_cpu(x) ((__force __u16)(__be16)(x))
# define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
# define __be64_to_cpu(x) ((__force __u64)(__be64)(x))
@@ -87,91 +87,91 @@
static inline void __le16_to_cpus(__u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab16s(p);
#endif
}
static inline void __cpu_to_le16s(__u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab16s(p);
#endif
}
static inline void __le32_to_cpus(__u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab32s(p);
#endif
}
static inline void __cpu_to_le32s(__u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab32s(p);
#endif
}
static inline void __le64_to_cpus(__u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab64s(p);
#endif
}
static inline void __cpu_to_le64s(__u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab64s(p);
#endif
}
static inline void __be16_to_cpus(__u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab16s(p);
#endif
}
static inline void __cpu_to_be16s(__u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab16s(p);
#endif
}
static inline void __be32_to_cpus(__u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab32s(p);
#endif
}
static inline void __cpu_to_be32s(__u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab32s(p);
#endif
}
static inline void __be64_to_cpus(__u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab64s(p);
#endif
}
static inline void __cpu_to_be64s(__u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab64s(p);
#endif
}
static inline __u16 __le16_to_cpup(const __le16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u16)*p;
#else
return __swab16p((__force __u16 *)p);
@@ -180,7 +180,7 @@ static inline __u16 __le16_to_cpup(const __le16 *p)
static inline __u32 __le32_to_cpup(const __le32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u32)*p;
#else
return __swab32p((__force __u32 *)p);
@@ -189,7 +189,7 @@ static inline __u32 __le32_to_cpup(const __le32 *p)
static inline __u64 __le64_to_cpup(const __le64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u64)*p;
#else
return __swab64p((__force __u64 *)p);
@@ -198,7 +198,7 @@ static inline __u64 __le64_to_cpup(const __le64 *p)
static inline __le16 __cpu_to_le16p(const __u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le16)*p;
#else
return (__force __le16)__swab16p(p);
@@ -207,7 +207,7 @@ static inline __le16 __cpu_to_le16p(const __u16 *p)
static inline __le32 __cpu_to_le32p(const __u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le32)*p;
#else
return (__force __le32)__swab32p(p);
@@ -216,7 +216,7 @@ static inline __le32 __cpu_to_le32p(const __u32 *p)
static inline __le64 __cpu_to_le64p(const __u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le64)*p;
#else
return (__force __le64)__swab64p(p);
@@ -225,7 +225,7 @@ static inline __le64 __cpu_to_le64p(const __u64 *p)
static inline __u16 __be16_to_cpup(const __be16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u16)*p;
#else
return __swab16p((__force __u16 *)p);
@@ -234,7 +234,7 @@ static inline __u16 __be16_to_cpup(const __be16 *p)
static inline __u32 __be32_to_cpup(const __be32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u32)*p;
#else
return __swab32p((__force __u32 *)p);
@@ -243,7 +243,7 @@ static inline __u32 __be32_to_cpup(const __be32 *p)
static inline __u64 __be64_to_cpup(const __be64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u64)*p;
#else
return __swab64p((__force __u64 *)p);
@@ -252,7 +252,7 @@ static inline __u64 __be64_to_cpup(const __be64 *p)
static inline __be16 __cpu_to_be16p(const __u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be16)*p;
#else
return (__force __be16)__swab16p(p);
@@ -261,7 +261,7 @@ static inline __be16 __cpu_to_be16p(const __u16 *p)
static inline __be32 __cpu_to_be32p(const __u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be32)*p;
#else
return (__force __be32)__swab32p(p);
@@ -270,7 +270,7 @@ static inline __be32 __cpu_to_be32p(const __u32 *p)
static inline __be64 __cpu_to_be64p(const __u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be64)*p;
#else
return (__force __be64)__swab64p(p);
--
1.6.1.rc2.316.geb2f0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-18 1:46 ` Harvey Harrison
0 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-18 1:46 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: bluebird, sparclinux, linux-kernel, David Miller
glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
which was tripping the check in linux/byteorder.h. Let's
just stay out of userspace's way and use __KERN_{endian}
The old implementation got away with it as it kept the two
implementations in different headers and conditionally included
the right one. The combined header does checks within each
function body and depends on only one being defined.
Converted the arches in mainline that have already moved to the
new header, as the other arches merge the will need simlar
fixups.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
arch/avr32/include/asm/byteorder.h | 2 +-
arch/mips/include/asm/byteorder.h | 4 +-
arch/sh/include/asm/byteorder.h | 4 +-
arch/sparc/include/asm/byteorder.h | 2 +-
include/linux/byteorder.h | 84 ++++++++++++++++++------------------
5 files changed, 48 insertions(+), 48 deletions(-)
diff --git a/arch/avr32/include/asm/byteorder.h b/arch/avr32/include/asm/byteorder.h
index 8e3af02..b7d6dd1 100644
--- a/arch/avr32/include/asm/byteorder.h
+++ b/arch/avr32/include/asm/byteorder.h
@@ -7,7 +7,7 @@
#include <asm/types.h>
#include <linux/compiler.h>
-#define __BIG_ENDIAN
+#define __KERN_BIG_ENDIAN
#define __SWAB_64_THRU_32__
#ifdef __CHECKER__
diff --git a/arch/mips/include/asm/byteorder.h b/arch/mips/include/asm/byteorder.h
index 2988d29..8ad8a5b 100644
--- a/arch/mips/include/asm/byteorder.h
+++ b/arch/mips/include/asm/byteorder.h
@@ -12,9 +12,9 @@
#include <asm/types.h>
#if defined(__MIPSEB__)
-# define __BIG_ENDIAN
+# define __KERN_BIG_ENDIAN
#elif defined(__MIPSEL__)
-# define __LITTLE_ENDIAN
+# define __KERN_LITTLE_ENDIAN
#else
# error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"
#endif
diff --git a/arch/sh/include/asm/byteorder.h b/arch/sh/include/asm/byteorder.h
index f5fa065..4aa5f1d 100644
--- a/arch/sh/include/asm/byteorder.h
+++ b/arch/sh/include/asm/byteorder.h
@@ -9,9 +9,9 @@
#include <linux/types.h>
#ifdef __LITTLE_ENDIAN__
-# define __LITTLE_ENDIAN
+# define __KERN_LITTLE_ENDIAN
#else
-# define __BIG_ENDIAN
+# define __KERN_BIG_ENDIAN
#endif
#define __SWAB_64_THRU_32__
diff --git a/arch/sparc/include/asm/byteorder.h b/arch/sparc/include/asm/byteorder.h
index 5a70f13..5b8347e 100644
--- a/arch/sparc/include/asm/byteorder.h
+++ b/arch/sparc/include/asm/byteorder.h
@@ -4,7 +4,7 @@
#include <asm/types.h>
#include <asm/asi.h>
-#define __BIG_ENDIAN
+#define __KERN_BIG_ENDIAN
#ifdef CONFIG_SPARC32
#define __SWAB_64_THRU_32__
diff --git a/include/linux/byteorder.h b/include/linux/byteorder.h
index 29f002d..3599fbc 100644
--- a/include/linux/byteorder.h
+++ b/include/linux/byteorder.h
@@ -4,33 +4,33 @@
#include <linux/types.h>
#include <linux/swab.h>
-#if defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)
+#if defined(__KERN_LITTLE_ENDIAN) && defined(__KERN_BIG_ENDIAN)
# error Fix asm/byteorder.h to define one endianness
#endif
-#if !defined(__LITTLE_ENDIAN) && !defined(__BIG_ENDIAN)
+#if !defined(__KERN_LITTLE_ENDIAN) && !defined(__KERN_BIG_ENDIAN)
# error Fix asm/byteorder.h to define arch endianness
#endif
-#ifdef __LITTLE_ENDIAN
-# undef __LITTLE_ENDIAN
-# define __LITTLE_ENDIAN 1234
+#ifdef __KERN_LITTLE_ENDIAN
+# ifndef __LITTLE_ENDIAN
+# define __LITTLE_ENDIAN 1234
+# endif
+# ifndef __LITTLE_ENDIAN_BITFIELD
+# define __LITTLE_ENDIAN_BITFIELD
+# endif
#endif
-#ifdef __BIG_ENDIAN
-# undef __BIG_ENDIAN
-# define __BIG_ENDIAN 4321
+#ifdef __KERN_BIG_ENDIAN
+# ifndef __BIG_ENDIAN
+# define __BIG_ENDIAN 4321
+# endif
+# ifndef __BIG_ENDIAN_BITFIELD
+# define __BIG_ENDIAN_BITFIELD
+# endif
#endif
-#if defined(__LITTLE_ENDIAN) && !defined(__LITTLE_ENDIAN_BITFIELD)
-# define __LITTLE_ENDIAN_BITFIELD
-#endif
-
-#if defined(__BIG_ENDIAN) && !defined(__BIG_ENDIAN_BITFIELD)
-# define __BIG_ENDIAN_BITFIELD
-#endif
-
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
# define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
# define __le32_to_cpu(x) ((__force __u32)(__le32)(x))
# define __le64_to_cpu(x) ((__force __u64)(__le64)(x))
@@ -46,7 +46,7 @@
# define __cpu_to_be64(x) ((__force __be64)__swab64(x))
#endif
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
# define __be16_to_cpu(x) ((__force __u16)(__be16)(x))
# define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
# define __be64_to_cpu(x) ((__force __u64)(__be64)(x))
@@ -87,91 +87,91 @@
static inline void __le16_to_cpus(__u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab16s(p);
#endif
}
static inline void __cpu_to_le16s(__u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab16s(p);
#endif
}
static inline void __le32_to_cpus(__u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab32s(p);
#endif
}
static inline void __cpu_to_le32s(__u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab32s(p);
#endif
}
static inline void __le64_to_cpus(__u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab64s(p);
#endif
}
static inline void __cpu_to_le64s(__u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
__swab64s(p);
#endif
}
static inline void __be16_to_cpus(__u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab16s(p);
#endif
}
static inline void __cpu_to_be16s(__u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab16s(p);
#endif
}
static inline void __be32_to_cpus(__u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab32s(p);
#endif
}
static inline void __cpu_to_be32s(__u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab32s(p);
#endif
}
static inline void __be64_to_cpus(__u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab64s(p);
#endif
}
static inline void __cpu_to_be64s(__u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
__swab64s(p);
#endif
}
static inline __u16 __le16_to_cpup(const __le16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u16)*p;
#else
return __swab16p((__force __u16 *)p);
@@ -180,7 +180,7 @@ static inline __u16 __le16_to_cpup(const __le16 *p)
static inline __u32 __le32_to_cpup(const __le32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u32)*p;
#else
return __swab32p((__force __u32 *)p);
@@ -189,7 +189,7 @@ static inline __u32 __le32_to_cpup(const __le32 *p)
static inline __u64 __le64_to_cpup(const __le64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __u64)*p;
#else
return __swab64p((__force __u64 *)p);
@@ -198,7 +198,7 @@ static inline __u64 __le64_to_cpup(const __le64 *p)
static inline __le16 __cpu_to_le16p(const __u16 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le16)*p;
#else
return (__force __le16)__swab16p(p);
@@ -207,7 +207,7 @@ static inline __le16 __cpu_to_le16p(const __u16 *p)
static inline __le32 __cpu_to_le32p(const __u32 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le32)*p;
#else
return (__force __le32)__swab32p(p);
@@ -216,7 +216,7 @@ static inline __le32 __cpu_to_le32p(const __u32 *p)
static inline __le64 __cpu_to_le64p(const __u64 *p)
{
-#ifdef __LITTLE_ENDIAN
+#ifdef __KERN_LITTLE_ENDIAN
return (__force __le64)*p;
#else
return (__force __le64)__swab64p(p);
@@ -225,7 +225,7 @@ static inline __le64 __cpu_to_le64p(const __u64 *p)
static inline __u16 __be16_to_cpup(const __be16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u16)*p;
#else
return __swab16p((__force __u16 *)p);
@@ -234,7 +234,7 @@ static inline __u16 __be16_to_cpup(const __be16 *p)
static inline __u32 __be32_to_cpup(const __be32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u32)*p;
#else
return __swab32p((__force __u32 *)p);
@@ -243,7 +243,7 @@ static inline __u32 __be32_to_cpup(const __be32 *p)
static inline __u64 __be64_to_cpup(const __be64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __u64)*p;
#else
return __swab64p((__force __u64 *)p);
@@ -252,7 +252,7 @@ static inline __u64 __be64_to_cpup(const __be64 *p)
static inline __be16 __cpu_to_be16p(const __u16 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be16)*p;
#else
return (__force __be16)__swab16p(p);
@@ -261,7 +261,7 @@ static inline __be16 __cpu_to_be16p(const __u16 *p)
static inline __be32 __cpu_to_be32p(const __u32 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be32)*p;
#else
return (__force __be32)__swab32p(p);
@@ -270,7 +270,7 @@ static inline __be32 __cpu_to_be32p(const __u32 *p)
static inline __be64 __cpu_to_be64p(const __u64 *p)
{
-#ifdef __BIG_ENDIAN
+#ifdef __KERN_BIG_ENDIAN
return (__force __be64)*p;
#else
return (__force __be64)__swab64p(p);
--
1.6.1.rc2.316.geb2f0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-18 1:46 ` Harvey Harrison
@ 2008-12-18 20:09 ` Linus Torvalds
-1 siblings, 0 replies; 21+ messages in thread
From: Linus Torvalds @ 2008-12-18 20:09 UTC (permalink / raw)
To: Harvey Harrison
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Wed, 17 Dec 2008, Harvey Harrison wrote:
>
> glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> which was tripping the check in linux/byteorder.h. Let's
> just stay out of userspace's way and use __KERN_{endian}
Gaah, ugly.
I think it would be better to just make it a config option, call it
CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
I think some of the people who can set it dynamically (or where it depends
on the target machine) already effectively do that.
Hmm?
Linus
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-18 20:09 ` Linus Torvalds
0 siblings, 0 replies; 21+ messages in thread
From: Linus Torvalds @ 2008-12-18 20:09 UTC (permalink / raw)
To: Harvey Harrison
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Wed, 17 Dec 2008, Harvey Harrison wrote:
>
> glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> which was tripping the check in linux/byteorder.h. Let's
> just stay out of userspace's way and use __KERN_{endian}
Gaah, ugly.
I think it would be better to just make it a config option, call it
CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
I think some of the people who can set it dynamically (or where it depends
on the target machine) already effectively do that.
Hmm?
Linus
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-18 20:09 ` Linus Torvalds
@ 2008-12-18 20:47 ` Linus Torvalds
-1 siblings, 0 replies; 21+ messages in thread
From: Linus Torvalds @ 2008-12-18 20:47 UTC (permalink / raw)
To: Harvey Harrison
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Thu, 18 Dec 2008, Linus Torvalds wrote:
>
> I think it would be better to just make it a config option, call it
> CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
> I think some of the people who can set it dynamically (or where it depends
> on the target machine) already effectively do that.
Never mind, since we end up having to export it to user space (do we?) we
can't depend on the config.h file, nor can we pollute the name space.
Oh well.
Linus
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-18 20:47 ` Linus Torvalds
0 siblings, 0 replies; 21+ messages in thread
From: Linus Torvalds @ 2008-12-18 20:47 UTC (permalink / raw)
To: Harvey Harrison
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Thu, 18 Dec 2008, Linus Torvalds wrote:
>
> I think it would be better to just make it a config option, call it
> CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
> I think some of the people who can set it dynamically (or where it depends
> on the target machine) already effectively do that.
Never mind, since we end up having to export it to user space (do we?) we
can't depend on the config.h file, nor can we pollute the name space.
Oh well.
Linus
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-18 20:47 ` Linus Torvalds
@ 2008-12-18 20:53 ` Harvey Harrison
-1 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-18 20:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Thu, 2008-12-18 at 12:47 -0800, Linus Torvalds wrote:
>
> On Thu, 18 Dec 2008, Linus Torvalds wrote:
> >
> > I think it would be better to just make it a config option, call it
> > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
> > I think some of the people who can set it dynamically (or where it depends
> > on the target machine) already effectively do that.
>
> Never mind, since we end up having to export it to user space (do we?) we
> can't depend on the config.h file, nor can we pollute the name space.
>
> Oh well.
I'm still having a bit of a think on this if we can avoid it. But I
think we're stuck with needing a different symbol. :-/
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-18 20:53 ` Harvey Harrison
0 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-18 20:53 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, bluebird, sparclinux, linux-kernel, David Miller
On Thu, 2008-12-18 at 12:47 -0800, Linus Torvalds wrote:
>
> On Thu, 18 Dec 2008, Linus Torvalds wrote:
> >
> > I think it would be better to just make it a config option, call it
> > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture Kconfig file.
> > I think some of the people who can set it dynamically (or where it depends
> > on the target machine) already effectively do that.
>
> Never mind, since we end up having to export it to user space (do we?) we
> can't depend on the config.h file, nor can we pollute the name space.
>
> Oh well.
I'm still having a bit of a think on this if we can avoid it. But I
think we're stuck with needing a different symbol. :-/
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-18 20:47 ` Linus Torvalds
@ 2008-12-19 8:08 ` Arjan van de Ven
-1 siblings, 0 replies; 21+ messages in thread
From: Arjan van de Ven @ 2008-12-19 8:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Harvey Harrison, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Thu, 18 Dec 2008 12:47:28 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 18 Dec 2008, Linus Torvalds wrote:
> >
> > I think it would be better to just make it a config option, call it
> > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture
> > Kconfig file. I think some of the people who can set it dynamically
> > (or where it depends on the target machine) already effectively do
> > that.
>
> Never mind, since we end up having to export it to user space (do
> we?) we can't depend on the config.h file, nor can we pollute the
> name space.
>
why are we exposing byte order functions to userspace in the first
place ????
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-19 8:08 ` Arjan van de Ven
0 siblings, 0 replies; 21+ messages in thread
From: Arjan van de Ven @ 2008-12-19 8:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Harvey Harrison, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Thu, 18 Dec 2008 12:47:28 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 18 Dec 2008, Linus Torvalds wrote:
> >
> > I think it would be better to just make it a config option, call it
> > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture
> > Kconfig file. I think some of the people who can set it dynamically
> > (or where it depends on the target machine) already effectively do
> > that.
>
> Never mind, since we end up having to export it to user space (do
> we?) we can't depend on the config.h file, nor can we pollute the
> name space.
>
why are we exposing byte order functions to userspace in the first
place ????
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-19 8:08 ` Arjan van de Ven
@ 2008-12-19 16:37 ` Harvey Harrison
-1 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-19 16:37 UTC (permalink / raw)
To: Arjan van de Ven, H. Peter Anvin, David Woodhouse
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Fri, 2008-12-19 at 09:08 +0100, Arjan van de Ven wrote:
> On Thu, 18 Dec 2008 12:47:28 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> >
> > On Thu, 18 Dec 2008, Linus Torvalds wrote:
> > >
> > > I think it would be better to just make it a config option, call it
> > > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture
> > > Kconfig file. I think some of the people who can set it dynamically
> > > (or where it depends on the target machine) already effectively do
> > > that.
> >
> > Never mind, since we end up having to export it to user space (do
> > we?) we can't depend on the config.h file, nor can we pollute the
> > name space.
> >
>
> why are we exposing byte order functions to userspace in the first
> place ????
>
Hysterical raisons. When I originally consolidated the byteorder stuff
I removed the userspace export. HPA (CC'd) made the point that this
API (rightly or wrongly) was currently exported and used by userspace
and we shouldn't pull the rug out from under them.
I would have liked to un-export it, then we could also make linux/byteorder.h
the preferred include instead of asm/ ... but we appear to be stuck with
historical baggage here.
Crazy idea: could a byteorder-user.h be added that make headers-export
will pick up instead of byteorder.h that the kernel _actually_ uses?
Then we could keep exporting _something_ to avoid breaking userspace
and allow the version the kernel actually uses to be evolved a bit
more easily?
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2008-12-19 16:37 ` Harvey Harrison
0 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2008-12-19 16:37 UTC (permalink / raw)
To: Arjan van de Ven, H. Peter Anvin, David Woodhouse
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Fri, 2008-12-19 at 09:08 +0100, Arjan van de Ven wrote:
> On Thu, 18 Dec 2008 12:47:28 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> >
> > On Thu, 18 Dec 2008, Linus Torvalds wrote:
> > >
> > > I think it would be better to just make it a config option, call it
> > > CONFIG_[LITTLE|BIG]_ENDIAN and set it up in the architecture
> > > Kconfig file. I think some of the people who can set it dynamically
> > > (or where it depends on the target machine) already effectively do
> > > that.
> >
> > Never mind, since we end up having to export it to user space (do
> > we?) we can't depend on the config.h file, nor can we pollute the
> > name space.
> >
>
> why are we exposing byte order functions to userspace in the first
> place ????
>
Hysterical raisons. When I originally consolidated the byteorder stuff
I removed the userspace export. HPA (CC'd) made the point that this
API (rightly or wrongly) was currently exported and used by userspace
and we shouldn't pull the rug out from under them.
I would have liked to un-export it, then we could also make linux/byteorder.h
the preferred include instead of asm/ ... but we appear to be stuck with
historical baggage here.
Crazy idea: could a byteorder-user.h be added that make headers-export
will pick up instead of byteorder.h that the kernel _actually_ uses?
Then we could keep exporting _something_ to avoid breaking userspace
and allow the version the kernel actually uses to be evolved a bit
more easily?
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2008-12-18 1:46 ` Harvey Harrison
@ 2009-01-06 10:23 ` Gerd Hoffmann
-1 siblings, 0 replies; 21+ messages in thread
From: Gerd Hoffmann @ 2009-01-06 10:23 UTC (permalink / raw)
To: Harvey Harrison
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
Harvey Harrison wrote:
> glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> which was tripping the check in linux/byteorder.h. Let's
> just stay out of userspace's way and use __KERN_{endian}
Ping. What is the status of this?
> Converted the arches in mainline that have already moved to the
> new header, as the other arches merge the will need simlar
> fixups.
In latest git powerpc, s390 and x86 are merged and need this fix too.
cheers,
Gerd
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2009-01-06 10:23 ` Gerd Hoffmann
0 siblings, 0 replies; 21+ messages in thread
From: Gerd Hoffmann @ 2009-01-06 10:23 UTC (permalink / raw)
To: Harvey Harrison
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
Harvey Harrison wrote:
> glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> which was tripping the check in linux/byteorder.h. Let's
> just stay out of userspace's way and use __KERN_{endian}
Ping. What is the status of this?
> Converted the arches in mainline that have already moved to the
> new header, as the other arches merge the will need simlar
> fixups.
In latest git powerpc, s390 and x86 are merged and need this fix too.
cheers,
Gerd
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
2009-01-06 10:23 ` Gerd Hoffmann
@ 2009-01-06 16:41 ` Harvey Harrison
-1 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2009-01-06 16:41 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Tue, 2009-01-06 at 11:23 +0100, Gerd Hoffmann wrote:
> Harvey Harrison wrote:
> > glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> > which was tripping the check in linux/byteorder.h. Let's
> > just stay out of userspace's way and use __KERN_{endian}
>
> Ping. What is the status of this?
>
> > Converted the arches in mainline that have already moved to the
> > new header, as the other arches merge the will need simlar
> > fixups.
>
> In latest git powerpc, s390 and x86 are merged and need this fix too.
>
> cheers,
> Gerd
I was waiting for the cris, xtensa and parisc arches to merge as they
have conversion patches in their arch trees. I'll send the patchset out
today with the proviso it shouldn't be applied until those three have
merged.
Cheers,
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH-2.6.28 final] byteorder: fix new headers for userspace
@ 2009-01-06 16:41 ` Harvey Harrison
0 siblings, 0 replies; 21+ messages in thread
From: Harvey Harrison @ 2009-01-06 16:41 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Linus Torvalds, Andrew Morton, bluebird, sparclinux,
linux-kernel, David Miller
On Tue, 2009-01-06 at 11:23 +0100, Gerd Hoffmann wrote:
> Harvey Harrison wrote:
> > glibc headers define both __LITTLE_ENDIAN and __BIG_ENDIAN
> > which was tripping the check in linux/byteorder.h. Let's
> > just stay out of userspace's way and use __KERN_{endian}
>
> Ping. What is the status of this?
>
> > Converted the arches in mainline that have already moved to the
> > new header, as the other arches merge the will need simlar
> > fixups.
>
> In latest git powerpc, s390 and x86 are merged and need this fix too.
>
> cheers,
> Gerd
I was waiting for the cris, xtensa and parisc arches to merge as they
have conversion patches in their arch trees. I'll send the patchset out
today with the proviso it shouldn't be applied until those three have
merged.
Cheers,
Harvey
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2009-01-06 16:41 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-12-13 15:55 Compiling glibc with 2.6.28 linux headers Friedrich Oslage
2008-12-16 9:13 ` David Miller
2008-12-16 9:13 ` David Miller
2008-12-17 1:22 ` Harvey Harrison
2008-12-17 1:22 ` Harvey Harrison
2008-12-18 1:46 ` [PATCH-2.6.28 final] byteorder: fix new headers for userspace Harvey Harrison
2008-12-18 1:46 ` Harvey Harrison
2008-12-18 20:09 ` Linus Torvalds
2008-12-18 20:09 ` Linus Torvalds
2008-12-18 20:47 ` Linus Torvalds
2008-12-18 20:47 ` Linus Torvalds
2008-12-18 20:53 ` Harvey Harrison
2008-12-18 20:53 ` Harvey Harrison
2008-12-19 8:08 ` Arjan van de Ven
2008-12-19 8:08 ` Arjan van de Ven
2008-12-19 16:37 ` Harvey Harrison
2008-12-19 16:37 ` Harvey Harrison
2009-01-06 10:23 ` Gerd Hoffmann
2009-01-06 10:23 ` Gerd Hoffmann
2009-01-06 16:41 ` Harvey Harrison
2009-01-06 16:41 ` Harvey Harrison
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.