arm: use the new byteorder headers
PATCH 2/23 arm: use the new byteorder headers
--- arch/arm/include/asm/byteorder.h | 25 +++++++++++-------------- 1 files changed, 11 insertions(+), 14 deletions(-)
arch/arm/include/asm/byteorder.h +11 -14
@@ -18,7 +18,15 @@#include <linux/compiler.h> #include <asm/types.h> -static inline __attribute_const__ __u32 ___arch__swab32(__u32 x) +#ifdef __ARMEB__ +# define __BIG_ENDIAN +#else +# define __LITTLE_ENDIAN +#endif + +#define __SWAB_64_THRU_32__ + +static inline __attribute_const__ __u32 __arch_swab32(__u32 x) {__u32 t;
@@ -40,19 +48,8 @@ static inline __attribute_const__ __u32 ___arch__swab32(__u32 x) return x; } +#define __arch_swab32 __arch_swab32 -#define __arch__swab32 (x) ___arch__swab32(x) - -#if !defined(__STRICT_ANSI__) || defined(__KERNEL__) -# define __BYTEORDER_HAS_U64__ -# define __SWAB_64_THRU_32__ -#endif - -#ifdef __ARMEB__ -#include <linux/byteorder/big_endian.h> -#else -#include <linux/byteorder/little_endian.h> -#endif +#include <linux/byteorder.h> #endif -
Signature · 1 line
1.6.0.274.g8aacc
Quoted 4 lines · Harvey Harrison
Signed-off-by Harvey Harrison <[email protected]>--- arch/arm/include/asm/byteorder.h | 25 +++++++++++-------------- 1 files changed, 11 insertions(+), 14 deletions(-)
You keep posting this, and it's the only bit I see, but... what about the other bits that it depends on, which without them, it's impossible to test this patch with?
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 10 lines · Russell King
Quoted 4 lines · Harvey Harrison
Signed-off-by Harvey Harrison <[email protected]>--- arch/arm/include/asm/byteorder.h | 25 +++++++++++-------------- 1 files changed, 11 insertions(+), 14 deletions(-)You keep posting this, and it's the only bit I see, but... what about the other bits that it depends on, which without them, it's impossible to test this patch with?
include/linux/swab.h, include/linux/byteorder.h are in current mainline which is all that these patches depend on.
Harvey
Quoted 2 lines · Harvey Harrison
include/linux/swab.h,include/linux/byteorder.hare in current mainline which is all that these patches depend on.
Er, it also depends on the patch which exports those headers to userspace, which isn't in Linus' tree yet.
So merging this for ARM (between -rc4 and rc5!) has broken the exported headers on ARM -- as noted by Khem.
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
Quoted 6 lines · David Woodhouse
Quoted 2 lines · Harvey Harrison
include/linux/swab.h,include/linux/byteorder.hare in current mainline which is all that these patches depend on.Er, it also depends on the patch which exports those headers to userspace, which isn't in Linus' tree yet.
How useful. If those generic headers are already in Linus' tree, and are required for architectures to convert, why hasn't the patch which exports them to userspace already been submitted?
However, another question: why should userspace be using a kernel header file for byteswapping?
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 11 lines · Russell King
Quoted 6 lines · David Woodhouse
Quoted 2 lines · Harvey Harrison
include/linux/swab.h,include/linux/byteorder.hare in current mainline which is all that these patches depend on.Er, it also depends on the patch which exports those headers to userspace, which isn't in Linus' tree yet.
How useful. If those generic headers are already in Linus' tree, and are required for architectures to convert, why hasn't the patch which exports them to userspace already been submitted?
Because they weren't being used by anything exported to userspace yet. The patch has been seen, but wasn't destined for 2.6.27...
Quoted 2 lines
However, another question: why should userspace be using a kernel header file for byteswapping?
... mostly (on my part, at least) because of that question.
Given my druthers, I'd revert the ARM part of the patch for now, and we can have a _serious_ think about whether we really need to export these functions to userspace.
A quick survey shows that the following user-visible headers currently use cpu_to_xxx() and xxx_to_cpu():
linux/romfs_fs.hlinux/bfs_fs.hlinux/ext2_fs.hlinux/reiserfs_fs.hlinux/msdos_fs.hlinux/ncp.hlinux/ncp_no.h
Of those, most of them use the form without underscores, which isn't visible in userspace _anyway_ and would be broken even if the new header is exported. I suspect that they should all just be dropped from the list of exported headers.
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
Quoted 16 lines · David Woodhouse
Quoted 11 lines · Russell King
Quoted 6 lines · David Woodhouse
Quoted 2 lines · Harvey Harrison
include/linux/swab.h,include/linux/byteorder.hare in current mainline which is all that these patches depend on.Er, it also depends on the patch which exports those headers to userspace, which isn't in Linus' tree yet.
How useful. If those generic headers are already in Linus' tree, and are required for architectures to convert, why hasn't the patch which exports them to userspace already been submitted?
Because they weren't being used by anything exported to userspace yet. The patch has been seen, but wasn't destined for 2.6.27...
Quoted 8 lines
Quoted 2 lines
However, another question: why should userspace be using a kernel header file for byteswapping?
... mostly (on my part, at least) because of that question.
Given my druthers, I'd revert the ARM part of the patch for now, and we can have a _serious_ think about whether we really need to export these functions to userspace.
I'll revert it, and if it's resubmitted, I'll ignore it until after the next merge window - since my tree for the upcoming merge window currently pre-dates the revert, so effectively continues to carry it until it's merged.
I'm not sure what went wrong, other than being continuously bugged by Harvey to apply his patch. If his patches are inappropriate, surely that should've been pointed out to Harvey before he got the first of his series merged?
Maybe more of his patches need reverting if some have been applied?
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: