[PATCH 1/2] Documentation/printk-formats.txt: No casts needed for u64/s64

[PATCH 1/2] Documentation/printk-formats.txt: No casts needed for u64/s64

[Geert Uytterhoeven]

Now all 64-bit architectures have been converted to int-ll64.h in kernel
space, casting to (unsigned) long long is no longer needed when formatting
u64/s64.

For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use
int-l64.h in userspace.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Cc: linux-doc@vger.kernel.org
---
This is the documentation part of more than two year old
"asm/types.h: All architectures use int-ll64.h in kernelspace"
(https://lkml.org/lkml/2011/8/13/104)

 Documentation/printk-formats.txt |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 3e8cb73..41aaed7 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -185,11 +185,11 @@ struct va_format:
 
 u64 SHOULD be printed with %llu/%llx, (unsigned long long):
 
-	printk("%llu", (unsigned long long)u64_var);
+	printk("%llu", u64_var);
 
 s64 SHOULD be printed with %lld/%llx, (long long):
 
-	printk("%lld", (long long)s64_var);
+	printk("%lld", s64_var);
 
 If <type> is dependent on a config option for its size (e.g., sector_t,
 blkcnt_t) or is architecture-dependent for its size (e.g., tcflag_t), use a
-- 
1.7.9.5

[PATCH 2/2] asm/types.h: Remove include/asm-generic/int-l64.h

[Geert Uytterhoeven]

Now all 64-bit architectures have been converted to int-ll64.h, we can
remove int-l64.h in kernelspace.

For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use
int-l64.h in userspace.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This is the (reworked for UAPI) non-documentation part of more than two
year old "asm/types.h: All architectures use int-ll64.h in kernelspace"
(https://lkml.org/lkml/2011/8/13/104)

Since <asm/types.h> (from include/uapi/asm-generic/types.h) is used for
both kernel and user space, include/asm-generic/int-ll64.h cannot just
become include/asm-generic/types.h, as Arnd suggested.

 include/asm-generic/int-l64.h    |   49 --------------------------------------
 include/uapi/asm-generic/types.h |    3 +--
 2 files changed, 1 insertion(+), 51 deletions(-)
 delete mode 100644 include/asm-generic/int-l64.h

diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
deleted file mode 100644
index 27d4ec0..0000000
--- a/include/asm-generic/int-l64.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * asm-generic/int-l64.h
- *
- * Integer declarations for architectures which use "long"
- * for 64-bit types.
- */
-#ifndef _ASM_GENERIC_INT_L64_H
-#define _ASM_GENERIC_INT_L64_H
-
-#include <uapi/asm-generic/int-l64.h>
-
-
-#ifndef __ASSEMBLY__
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long s64;
-typedef unsigned long u64;
-
-#define S8_C(x)  x
-#define U8_C(x)  x ## U
-#define S16_C(x) x
-#define U16_C(x) x ## U
-#define S32_C(x) x
-#define U32_C(x) x ## U
-#define S64_C(x) x ## L
-#define U64_C(x) x ## UL
-
-#else /* __ASSEMBLY__ */
-
-#define S8_C(x)  x
-#define U8_C(x)  x
-#define S16_C(x) x
-#define U16_C(x) x
-#define S32_C(x) x
-#define U32_C(x) x
-#define S64_C(x) x
-#define U64_C(x) x
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* _ASM_GENERIC_INT_L64_H */
diff --git a/include/uapi/asm-generic/types.h b/include/uapi/asm-generic/types.h
index bd39806..a387792 100644
--- a/include/uapi/asm-generic/types.h
+++ b/include/uapi/asm-generic/types.h
@@ -1,8 +1,7 @@
 #ifndef _ASM_GENERIC_TYPES_H
 #define _ASM_GENERIC_TYPES_H
 /*
- * int-ll64 is used practically everywhere now,
- * so use it as a reasonable default.
+ * int-ll64 is used everywhere now.
  */
 #include <asm-generic/int-ll64.h>
 
-- 
1.7.9.5

[PATCH RESEND] asm/types.h: Remove include/asm-generic/int-l64.h

[Geert Uytterhoeven]

Now all 64-bit architectures have been converted to int-ll64.h, we can
remove int-l64.h in kernelspace.

For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use
int-l64.h in userspace.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
This is the (reworked for UAPI) non-documentation part of more than two
year old "asm/types.h: All architectures use int-ll64.h in kernelspace"
(https://lkml.org/lkml/2011/8/13/104)

Since <asm/types.h> (from include/uapi/asm-generic/types.h) is used for
both kernel and user space, include/asm-generic/int-ll64.h cannot just
become include/asm-generic/types.h, as Arnd suggested.

 include/asm-generic/int-l64.h    |   49 --------------------------------------
 include/uapi/asm-generic/types.h |    3 +--
 2 files changed, 1 insertion(+), 51 deletions(-)
 delete mode 100644 include/asm-generic/int-l64.h

diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
deleted file mode 100644
index 27d4ec0dfce0..000000000000
--- a/include/asm-generic/int-l64.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * asm-generic/int-l64.h
- *
- * Integer declarations for architectures which use "long"
- * for 64-bit types.
- */
-#ifndef _ASM_GENERIC_INT_L64_H
-#define _ASM_GENERIC_INT_L64_H
-
-#include <uapi/asm-generic/int-l64.h>
-
-
-#ifndef __ASSEMBLY__
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long s64;
-typedef unsigned long u64;
-
-#define S8_C(x)  x
-#define U8_C(x)  x ## U
-#define S16_C(x) x
-#define U16_C(x) x ## U
-#define S32_C(x) x
-#define U32_C(x) x ## U
-#define S64_C(x) x ## L
-#define U64_C(x) x ## UL
-
-#else /* __ASSEMBLY__ */
-
-#define S8_C(x)  x
-#define U8_C(x)  x
-#define S16_C(x) x
-#define U16_C(x) x
-#define S32_C(x) x
-#define U32_C(x) x
-#define S64_C(x) x
-#define U64_C(x) x
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* _ASM_GENERIC_INT_L64_H */
diff --git a/include/uapi/asm-generic/types.h b/include/uapi/asm-generic/types.h
index bd39806013b5..a3877926b0d4 100644
--- a/include/uapi/asm-generic/types.h
+++ b/include/uapi/asm-generic/types.h
@@ -1,8 +1,7 @@
 #ifndef _ASM_GENERIC_TYPES_H
 #define _ASM_GENERIC_TYPES_H
 /*
- * int-ll64 is used practically everywhere now,
- * so use it as a reasonable default.
+ * int-ll64 is used everywhere now.
  */
 #include <asm-generic/int-ll64.h>
 
-- 
1.7.9.5

Re: [PATCH RESEND] asm/types.h: Remove include/asm-generic/int-l64.h

[Arnd Bergmann]

On Tuesday 19 November 2013, Geert Uytterhoeven wrote:
> Now all 64-bit architectures have been converted to int-ll64.h, we can
> remove int-l64.h in kernelspace.
> 
> For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use
> int-l64.h in userspace.
> 
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks for following up with this.

> ---
> This is the (reworked for UAPI) non-documentation part of more than two
> year old "asm/types.h: All architectures use int-ll64.h in kernelspace"
> (https://lkml.org/lkml/2011/8/13/104)
> 
> Since <asm/types.h> (from include/uapi/asm-generic/types.h) is used for
> both kernel and user space, include/asm-generic/int-ll64.h cannot just
> become include/asm-generic/types.h, as Arnd suggested.

I'm pretty sure you are right with this, but I don't remember at all
what I suggested and don't understand what the problem (if any) is.
Can you remind me?

	Arnd

Re: [PATCH RESEND] asm/types.h: Remove include/asm-generic/int-l64.h

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Nov 19, 2013 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 19 November 2013, Geert Uytterhoeven wrote:
>> Now all 64-bit architectures have been converted to int-ll64.h, we can
>> remove int-l64.h in kernelspace.
>>
>> For backwards compatibility, alpha, ia64, mips64, and powerpc64 still use
>> int-l64.h in userspace.
>>
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>

Thanks!

>> Since <asm/types.h> (from include/uapi/asm-generic/types.h) is used for
>> both kernel and user space, include/asm-generic/int-ll64.h cannot just
>> become include/asm-generic/types.h, as Arnd suggested.
>
> I'm pretty sure you are right with this, but I don't remember at all
> what I suggested and don't understand what the problem (if any) is.
> Can you remind me?

Me neither :-(
You said https://lkml.org/lkml/2011/8/13/109, and Al's umode_t
consolidation has been completed.

I think it had to do with include/uapi/asm-generic/types.h including
<asm-generic/int-ll64.h>. Let's try...

In userspace, it will include <asm-generic/int-ll64.h> from uapi to get
e.g. __u32.
In kernelspace, it will include plain <asm-generic/int-ll64.h> (to get e.g.
u32), which will in turn include <uapi/asm-generic/int-ll64.h> (to also
get e.g. __u32).

As there's only include/uapi/asm-generic/types.h, but not
include/asm-generic/types.h (the individual architectures still have their
own asm/types.h), you cannot easily move (the contents of) int-ll64.h
to asm-generic/types.h for both the normal and uapi headers.

Does this make sense?

Note that this discussion is about what to do with the remaining int-ll64.h,
not about removing int-l64.h, which is what this patch is really about.
So _this_ patch can just go in.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH RESEND] asm/types.h: Remove include/asm-generic/int-l64.h

[Arnd Bergmann]

On Tuesday 19 November 2013, Geert Uytterhoeven wrote:
> On Tue, Nov 19, 2013 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > I'm pretty sure you are right with this, but I don't remember at all
> > what I suggested and don't understand what the problem (if any) is.
> > Can you remind me?
> 
> Me neither :-(
> You said https://lkml.org/lkml/2011/8/13/109, and Al's umode_t
> consolidation has been completed.
> 
> I think it had to do with include/uapi/asm-generic/types.h including
> <asm-generic/int-ll64.h>. Let's try...
> 
> In userspace, it will include <asm-generic/int-ll64.h> from uapi to get
> e.g. __u32.
> In kernelspace, it will include plain <asm-generic/int-ll64.h> (to get e.g.
> u32), which will in turn include <uapi/asm-generic/int-ll64.h> (to also
> get e.g. __u32).
> 
> As there's only include/uapi/asm-generic/types.h, but not
> include/asm-generic/types.h (the individual architectures still have their
> own asm/types.h), you cannot easily move (the contents of) int-ll64.h
> to asm-generic/types.h for both the normal and uapi headers.
> 
> Does this make sense?

I'm pretty sure I was not talking about include/uapi/asm-generic/types.h
there, and I still think we can just move include/asm-generic/int-ll64.h
to include/asm-generic/types.h but leave the uapi logic in place.

All architectures that do nothing but #include <asm-generic/int-ll64.h>
from asm/types.h at the moment can then remove their private file and
use the generic version, the others need to change to #include 
<asm-generic/types.h>.

You can no longer #include <uapi/asm-generic/types.h> from kernel space
after this change, since it refers to <asm-generic/int-ll64.h> which
now only exists in user space, but that's ok because it would be a bug
to include already (it defines the wrong types), and we don't.

> Note that this discussion is about what to do with the remaining int-ll64.h,
> not about removing int-l64.h, which is what this patch is really about.
> So _this_ patch can just go in.

Right.

	Arnd

Re: [PATCH RESEND] asm/types.h: Remove include/asm-generic/int-l64.h

[Geert Uytterhoeven]

On Wed, Nov 20, 2013 at 1:37 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 19 November 2013, Geert Uytterhoeven wrote:
>> On Tue, Nov 19, 2013 at 1:35 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> > I'm pretty sure you are right with this, but I don't remember at all
>> > what I suggested and don't understand what the problem (if any) is.
>> > Can you remind me?
>>
>> Me neither :-(
>> You said https://lkml.org/lkml/2011/8/13/109, and Al's umode_t
>> consolidation has been completed.
>>
>> I think it had to do with include/uapi/asm-generic/types.h including
>> <asm-generic/int-ll64.h>. Let's try...
>>
>> In userspace, it will include <asm-generic/int-ll64.h> from uapi to get
>> e.g. __u32.
>> In kernelspace, it will include plain <asm-generic/int-ll64.h> (to get e.g.
>> u32), which will in turn include <uapi/asm-generic/int-ll64.h> (to also
>> get e.g. __u32).
>>
>> As there's only include/uapi/asm-generic/types.h, but not
>> include/asm-generic/types.h (the individual architectures still have their
>> own asm/types.h), you cannot easily move (the contents of) int-ll64.h
>> to asm-generic/types.h for both the normal and uapi headers.
>>
>> Does this make sense?
>
> I'm pretty sure I was not talking about include/uapi/asm-generic/types.h
> there, and I still think we can just move include/asm-generic/int-ll64.h
> to include/asm-generic/types.h but leave the uapi logic in place.

The puzzle pieces are starting to fit: at that time, we still had
include/asm-generic/types.h, which got later renamed to
include/uapi/asm-generic/types.h...

> All architectures that do nothing but #include <asm-generic/int-ll64.h>
> from asm/types.h at the moment can then remove their private file and
> use the generic version, the others need to change to #include
> <asm-generic/types.h>.
>
> You can no longer #include <uapi/asm-generic/types.h> from kernel space
> after this change, since it refers to <asm-generic/int-ll64.h> which
> now only exists in user space, but that's ok because it would be a bug
> to include already (it defines the wrong types), and we don't.

I'll see what I can do...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds