[PATCH v2] linux/types.h: always export 64bit aligned defines

[PATCH v2] linux/types.h: always export 64bit aligned defines

[Mike Frysinger]

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>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jan Engelhardt <jengelh@computergmbh.de>
Cc: Patrick McHardy <kaber@trash.net>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
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

Re: [PATCH v2] linux/types.h: always export 64bit aligned defines

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> 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, schwab@suse.de
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."

Re: [PATCH v2] linux/types.h: always export 64bit aligned defines

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH v2] linux/types.h: always export 64bit aligned defines

[Andreas Schwab]

Mike Frysinger <vapier@gentoo.org> writes:

> On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
>> Mike Frysinger <vapier@gentoo.org> 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, schwab@suse.de
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."

Re: [PATCH v2] linux/types.h: always export 64bit aligned defines

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

On Friday 02 January 2009 16:59:35 Andreas Schwab wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On Friday 02 January 2009 09:24:39 Andreas Schwab wrote:
> >> Mike Frysinger <vapier@gentoo.org> 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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: [PATCH v2] linux/types.h: always export 64bit aligned defines

[Arnd Bergmann]

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