Thread (40 messages) flat view 40 messages, 14 authors, 2008-07-22

Re: the printk problem

From: Matthew Wilcox <hidden>
Date: 2008-07-04 20:43:08

On Fri, Jul 04, 2008 at 01:27:16PM -0700, Andrew Morton wrote:
On Fri, 4 Jul 2008 13:02:05 -0700 (PDT) Linus Torvalds [off-list ref] wrote:
quoted
quoted
so I think we could easily just say that we extend %p in various ways:

 - %pS - print pointer as a symbol

and leave tons of room for future extensions for different kinds of 
pointers. 
If this takes off we might want a register-your-printk-handler
interface.  Maybe.

We also jump through hoops to print things like sector_t and
resource_size_t.  They always need to be cast to `unsiged long long',
which generates additional stack space and text in some setups.
The thing is that GCC checks types.  So it's fine to add "print this
pointer specially", but you can't in general add new printf arguments
without also hacking GCC.  Unless you use -Wno-format, and require
sparse to check special kernel types.
And then there's the perennial "need to cast u64 to unsigned long long
to print it".  If we were to do

	printk("%SL", (void *)some_u64);

then that's still bloody ugly, but it'll save a little text-n-stack.
u64 is easy to fix, and I don't know why we haven't.  Just make it
unsigned long long on all architectures.

-- 
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."
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help