[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1214406026.21847.25.camel@johannes.berg>
Date: Wed, 25 Jun 2008 17:00:26 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Paul Jackson <pj@....com>, hpa@...or.com, yhlu.kernel@...il.com,
akpm@...ux-foundation.org, mingo@...e.hu, tglx@...utronix.de,
steiner@....com, travis@....com, linux-kernel@...r.kernel.org,
ying.huang@...el.com, andi@...stfloor.org
Subject: Re: [PATCH 4/5 v2] x86 boot: show pfn addresses in hex not decimal
in some kernel info printks
On Tue, 2008-06-24 at 21:04 -0700, Linus Torvalds wrote:
> It's really irritating how we cannot extend on the printk strings without
> either having to throw out gcc warnings altogether. gcc has no extension
> mechanism to the built-in rules ;/
>
> The format warnings are too useful to drop entirely. I guess sparse could
> be taught to do them, and then we could drop the gcc support for them. But
> that would still limit coverage a _lot_.
We should probably start working on getting this fixed.
In networking, we've gone through various incarnations of print_mac()
which is similar to the sym() macro Paul proposed, and it turned out to
be undesirable because of the way it interacts with static inlines that
only optionally contain code at all, the print_mac() function call is
still emitted by the compiler. People experimented with marking it
__pure but that had other problems.
It would be nice to be able to say
u8 *eaddr;
printk(... %M ..., eaddr);
and get
03:45:67:89:ab:cd
out of it, which avoids both the large string/code you get when doing it
manually (printf("%2.x:...:%.2x", eaddr[0], ...) for which there are
macros) and the "function call in hotpath even when debugging is
disabled" problem I mentioned above.
johannes
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists