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 <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: David Woodhouse <[email protected]>
Cc: Jan Engelhardt <[email protected]>
Cc: Patrick McHardy <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
v1
- update after the net tree merge which broke previous patch
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 121f349..7c0601b 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 __u64 __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.
*
@@ -156,6 +151,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 __u64 __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.6.0.6
Mike Frysinger <[email protected]> writes:
> 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.
aligned_u64 would pollute the name space, wouldn't it?
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
> Mike Frysinger <[email protected]> writes:
> > 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.
>
> aligned_u64 would pollute the name space, wouldn't it?
if by "pollute the name space" you mean "it'll be defined where it normally
wasnt before", then yes. it's always been in the header, just behind
__KERNEL_STRICT_NAMES. i also highlight the fact that existing headers that
are exported to userspace are already using this type, so they're broken most
of the time today.
unless you want a completely new patch that deletes aligned_*64 types and
replaces them with __aligned_*64 types ...
-mike
Mike Frysinger <[email protected]> writes:
> On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
>> Mike Frysinger <[email protected]> writes:
>> > 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.
>>
>> aligned_u64 would pollute the name space, wouldn't it?
>
> if by "pollute the name space" you mean "it'll be defined where it normally
> wasnt before", then yes.
I mean that it may conflict with normal userspace which is the whole
point of being hidden.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Friday 02 January 2009 16:59:35 Andreas Schwab wrote:
> Mike Frysinger <[email protected]> writes:
> > On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
> >> Mike Frysinger <[email protected]> writes:
> >> > 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.
> >>
> >> aligned_u64 would pollute the name space, wouldn't it?
> >
> > if by "pollute the name space" you mean "it'll be defined where it
> > normally wasnt before", then yes.
>
> I mean that it may conflict with normal userspace which is the whole
> point of being hidden.
no, there is nothing in userspace that i know of that defines this type. i
mentioned this in the changelog already.
-mike
On Friday 02 January 2009, Mike Frysinger wrote:
> On Friday 02 January 2009 16:59:35 Andreas Schwab wrote:
>
> > I mean that it may conflict with normal userspace which is the whole
> > point of being hidden.
>
> no, there is nothing in userspace that i know of that defines this type. ?i
> mentioned this in the changelog already.
What Andreas is trying to explain to you is that the definition of
__KERNEL_STRICT_NAMES is that you would get no definitions that can
possibly pollute the name space, rather than not adding any known
conflicts (which we try with and without __KERNEL_STRICT_NAMES).
The correct patch would add new definitions for __kernel_aligned_{u,be,le}64
types that can be safely used in public data structures even with
__KERNEL_STRICT_NAMES set, and then add the existing names
for convenience for use inside of the kernel, as we do for all the
common types.
Arnd <><