All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.