Some kernel headers exported to userspace rely on these 64bit aligned defines.

However, they are hidden behind __KERNEL_STRICT_NAMES at the moment which

means most of the time, they're never actually available.  These these defines

dont actually conflict with normal userspace / C library types, there's no

reason to hide them behind the __KERNEL_STRICT_NAMES define.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>

---

 include/linux/types.h |   10 +++++-----

 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/types.h b/include/linux/types.h

index f4f8d19..b80a263 100644

--- a/include/linux/types.h

+++ b/include/linux/types.h

@@ -125,11 +125,6 @@ typedef		__u64		u_int64_t;

 typedef		__s64		int64_t;

 #endif
-/* this is a special 64bit data type that is 8-byte aligned */

-#define aligned_u64 unsigned long long __attribute__((aligned(8)))

-#define aligned_be64 __be64 __attribute__((aligned(8)))

-#define aligned_le64 __le64 __attribute__((aligned(8)))

-

 /**

  * The type used for indexing onto a disc or disc partition.

  *

@@ -161,6 +156,11 @@ typedef unsigned long blkcnt_t;
 #endif /* __KERNEL_STRICT_NAMES */
+/* this is a special 64bit data type that is 8-byte aligned */

+#define aligned_u64 unsigned long long __attribute__((aligned(8)))

+#define aligned_be64 __be64 __attribute__((aligned(8)))

+#define aligned_le64 __le64 __attribute__((aligned(8)))

+

 /*

  * Below are truly Linux-specific types that should never collide with

  * any application/library that wants linux/types.h.

--

1.5.3.8

--

Maybe we shouldn't be using these helper macros in exported-to-userspace

headers.  Do you know which headers are affected?  Did you consider jsut
Seems relatively harmless.
But I'd have thought that if we're going to do this, we should create a

standard naming convention for types which the kernel exports to userspace.

Say, kern_*.
In which case the change becomes:
#define kern_aligned_u64 unsigned long long __attribute__((aligned(8)))

#define kern_aligned_be64 __be64 __attribute__((aligned(8)))

#define kern_aligned_le64 __le64 __attribute__((aligned(8)))
(exported to userspace)
and, inside __KERNEL__:
#define aligned_u64 kern_aligned_u64
etc.  And, of course, all those bit of kernel headers which are presently

using aligned_u64 in exposed-to-userspace places should be switched to

kern_aligned_u4.
What thinkest thou?
If _that_ is all sane then we should do it all in a singe header file, say

kern_types_for_userspace.h.  include/linux/types.h would then do:
#include <linux/kern_types_for_userspace.h>
#ifdef __KERNEL__

#define aligned_u64 kern_aligned_u64

etc...
(all approximate, you-get-what-I-mean)
Duno if it'd be worth the effort, but it is The Right Thing To Do.
--

Wrong way. They are inside #ifndef __KERNEL_STRICT_NAMES, so
grep aligned_u64 include/linux/netfilter{,ipv4,ipv6}/*.h
iptables uses that, but we can get rid of it if need be.
... so could use __attribute__((aligned(8))) directly for exported

headers, like we currently do for pointers (since there is no
--

i'm thinking the right way, i just may not have expressed it completely=20
for all practical purposes, they are not.  glibc will define=20

__KERNEL_STRICT_NAMES because (like a sane C lib), it defines all of the=20

basic types that the kernel also defines.

=2Dmike

Phew - now we have two sorts of userspace? (Those with glibc and

those without, aka standalone). Right, it's messy, which is why

this thread exists and a better solution is sought :)

--