Re: [PATCH] lib: vsprintf: Add %pa format specifier for phys_addr_ttypes

[Stepan Moskovchenko]

> On Tue, 2013-01-22 at 23:26 +0100, Geert Uytterhoeven wrote:
> > On Tue, Jan 22, 2013 at 6:47 AM, Stepan Moskovchenko
> > <stepanm@xxxxxxxxxxxxxx> wrote:
> > > Add the %pa format specifier for printing a phys_addr_t
> > > type, since the physical address size on some platforms
> > > can vary based on build options, regardless of the native
> > > integer type.
> >
> > I'm not so sure it's a good idea to start using %p for integer types.
>
> It would also require that some automatic variables
> that could otherwise be used in registers be put on
> the stack.

When calling something like printk on a variable, is that really a big 
concern in the grand scheme of things? On a system with a 32-bit 
phys_addr_t type, how does the overhead of having to put the variable on 
the stack compare to the overhead needed to cast to an unsigned long 
long and emit the eight extra '0' characters when printing a formatted 
physical address? If allocation efficiency is a big concern for a 
particular code path, the caller is always free to continue to cast to 
unsigned long long and use %llu, if they don't mind extra padding where 
phys_addr_t is smaller than a long long. But considering this is 
primarily meant to be used by printk during initialization / debug / 
error handling paths, there will be plenty of other overhead involved in 
producing log output.

As far as type safety is concerned, the %p specifier is already willing 
to accept pointers to all sorts of things which it is powerless to 
check, and it is up to the caller to do the right thing.

Printing out a physical address is a pretty reasonable thing for a 
driver to do in an init or debug path. It is conceivable that the same 
driver may be used on a system with 32-bit ore >32-bit physical address 
types. With something like ARM LPAE, it is even possible for the same 
system to use 32-bit and >32-bit addressing based strictly on build 
options, while still using the same drivers, meaning that the drivers 
would need to deal with phys_addr_t being of variable size. It also 
seems like a potential bit of extra overhead is not worth the ugliness 
of casting each phys_addr_t to an unsigned long long and printing it as 
a 64-bit type regardless of the actual number of address bits available. 
If a driver is really concerned about efficiency of its init paths, it 
is free to continue using %llu, or better yet, cut down on the amount of 
log spam these paths generate.

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/