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