public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linus <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: trace: fix printk warning for u64
Date: Tue, 28 Oct 2008 10:08:46 +0100	[thread overview]
Message-ID: <20081028090846.GR15734@elte.hu> (raw)
In-Reply-To: <20081027220655.1d188e1d.akpm@linux-foundation.org>


* Andrew Morton <akpm@linux-foundation.org> wrote:

> On Tue, 28 Oct 2008 00:12:54 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > Hi Ingo,
> > 
> > On Mon, 27 Oct 2008 10:52:48 +0100 Ingo Molnar <mingo@elte.hu> wrote:
> > >
> > > (btw., did the "unify u64 definitions across all platforms" project 
> > > get anywhere?)
> > 
> > I think (from a comment from DaveM) that it led into a real mess.
> 
> The problem is the large amount of arch-specific code which is 
> printing u64's with %lu because it "knows" that u64 is implemented 
> as ulong. They all need to be switched to %ll.
> 
> A better strategy to get all this done would be to convert the 
> offending architectures to `long long' individually.  Then when 
> that's all done, unifying the typedef is a trivial step.

so here's the patch below which achieves just that. 64-bit platforms 
using the old int-l64.h header will get build warnings which they can 
fix gradually.

There's no runtime failures expected, nor any non-warning build 
failures, correct? So lets just do this, hm?

	Ingo

---
 include/asm-generic/int-l64.h |   63 +---------------------------------------
 1 files changed, 2 insertions(+), 61 deletions(-)

diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
index 2af9b75..a152df9 100644
--- a/include/asm-generic/int-l64.h
+++ b/include/asm-generic/int-l64.h
@@ -1,71 +1,12 @@
 /*
  * asm-generic/int-l64.h
  *
- * Integer declarations for architectures which use "long"
- * for 64-bit types.
+ * migration helper, will go away soon.
  */
 
 #ifndef _ASM_GENERIC_INT_L64_H
 #define _ASM_GENERIC_INT_L64_H
 
-#ifndef __ASSEMBLY__
-/*
- * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
- * header files exported to user space
- */
-
-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;
-
-#endif /* __ASSEMBLY__ */
-
-#ifdef __KERNEL__
-
-#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 /* __KERNEL__ */
+#include <asm-generic/int-ll64.h>
 
 #endif /* _ASM_GENERIC_INT_L64_H */

  reply	other threads:[~2008-10-28  9:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-27  6:43 trace: fix printk warning for u64 Stephen Rothwell
2008-10-27  9:52 ` Ingo Molnar
2008-10-27 13:12   ` Stephen Rothwell
2008-10-28  5:06     ` Andrew Morton
2008-10-28  9:08       ` Ingo Molnar [this message]
2008-10-27 10:26 ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081028090846.GR15734@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox