linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, Peter Anvin <hpa@zytor.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: the printk problem
Date: Fri, 4 Jul 2008 20:03:51 -0600	[thread overview]
Message-ID: <20080705020350.GN14894@parisc-linux.org> (raw)
In-Reply-To: <20080704150100.1f7b8a65.akpm@linux-foundation.org>

On Fri, Jul 04, 2008 at 03:01:00PM -0700, Andrew Morton wrote:
> (heck, let's cc lkml - avoid having to go through all this again)
> 
> It would be excellent if gcc had an extension system so that you could
> add new printf control chars and maybe even tell gcc how to check them.
> But of course, if that were to happen, we couldn't use it for 4-5 years.

I believe NetBSD added that as an extension many years ago.  Dunno if
they still have it.

> What I had initially proposed was to abuse %S, which takes a wchar_t*. 
> gcc accepts `unsigned long *' for %S.
> 
[...]
> - there's a cast, so you could accidentally do
> 
> 	printk("here is an inode: %Si\n", (unsigned long *)dentry);
> 
> - there's a cast, and they're ugly
> 
> - gcc cannot of course check that the arg matches the control string
> 
> Unfortunately (and this seems weird), gcc printf checking will not
> accept a void* for %S: it _has_ to be wchar_t*, and the checker won't
> permit void* substitution for that.

Presumably that's the compiler getting rid of the first and third
downside ;-)

> Anyway, Linus took all that and said "let's abuse %p instead".  It
> _will_ accept any pointer so we can instead do:
> 
> 	printk("here is an inode: %pi\n", inode);
> 
> which is nicer.

Yes.  It's possible to confuse it, of course.

	printk("Function %pSucks\n", sys_open);

but I really doubt we have such a usage in the kernel today.

> > u64 is easy to fix, and I don't know why we haven't.  Just make it
> > unsigned long long on all architectures.
> 
> Yeah.  Why don't we do that?

Patch ...

[PATCH] Make u64 long long on all architectures

It is currently awkward to print a u64 type.  Some architectures use
unsigned long while others use unsigned long long.  Since unsigned long
long is 64-bit for all existing Linux architectures, change those that
use long to use long long.  Note that this applies only within the
kernel.  If u64 is being used in a C++ method definition, the symbol
mangling would change.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>

diff --git a/include/asm-generic/int-l64.h b/include/asm-generic/int-l64.h
index 2af9b75..32f07bd 100644
--- a/include/asm-generic/int-l64.h
+++ b/include/asm-generic/int-l64.h
@@ -23,8 +23,13 @@ typedef unsigned short __u16;
 typedef __signed__ int __s32;
 typedef unsigned int __u32;
 
+#ifdef __KERNEL__
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#else
 typedef __signed__ long __s64;
 typedef unsigned long __u64;
+#endif
 
 #endif /* __ASSEMBLY__ */
 

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-07-05  2:03 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080625131101.GA6205@digi.com>
     [not found] ` <20080704104634.GA31634@digi.com>
     [not found]   ` <20080704111540.ddffd241.akpm@linux-foundation.org>
     [not found]     ` <alpine.LFD.1.10.0807041147450.2815@woody.linux-foundation.org>
2008-07-04 20:02       ` the printk problem Linus Torvalds
2008-07-04 20:27         ` Andrew Morton
2008-07-04 20:41           ` Linus Torvalds
2008-07-04 20:42           ` Matthew Wilcox
2008-07-04 22:01             ` Andrew Morton
2008-07-05  2:03               ` Matthew Wilcox [this message]
2008-07-22 10:05                 ` [PATCH] Make u64 long long on all architectures (was: the printk problem) Andrew Morton
2008-07-22 10:36                   ` Michael Ellerman
2008-07-22 10:53                     ` Andrew Morton
2008-07-22 11:36                     ` Benjamin Herrenschmidt
2008-07-22 11:35                   ` Benjamin Herrenschmidt
2008-07-05 10:20               ` the printk problem Denys Vlasenko
2008-07-05 11:33               ` Jan Engelhardt
2008-07-05 12:52                 ` Vegard Nossum
2008-07-05 13:24                   ` Jan Engelhardt
2008-07-05 13:50                     ` Vegard Nossum
2008-07-05 14:07                       ` Jan Engelhardt
2008-07-05 17:56                   ` Linus Torvalds
2008-07-05 18:40                     ` Jan Engelhardt
2008-07-05 18:44                       ` Linus Torvalds
2008-07-05 18:41                     ` Vegard Nossum
2008-07-05 18:52                       ` Matthew Wilcox
2008-07-06  0:02                         ` Pekka Enberg
2008-07-06  5:17                           ` Randy Dunlap
2008-07-04 22:58             ` Benjamin Herrenschmidt
2008-07-04 20:36         ` Matthew Wilcox
2008-07-08  1:44           ` Kyle McMartin
2008-07-04 23:00         ` Benjamin Herrenschmidt
2008-07-04 23:25           ` Linus Torvalds
2008-07-05 22:32             ` Linus Torvalds
2008-07-05 22:57               ` Arjan van de Ven
2008-07-06  5:27               ` Ingo Molnar
2008-07-06  5:37                 ` Linus Torvalds
2008-07-06  5:53                   ` Ingo Molnar
2008-07-06  6:13                     ` Ingo Molnar
2008-07-07  1:14             ` Benjamin Herrenschmidt
2008-07-07  3:26               ` Stephen Rothwell
2008-07-07  3:28                 ` Michael Ellerman
2008-07-07  4:59                   ` Stephen Rothwell
2008-07-07  3:43                 ` Benjamin Herrenschmidt

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=20080705020350.GN14894@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --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;
as well as URLs for NNTP newsgroup(s).